Le 22 septembre 2026, WordPress a publié la version 7.1.2. Une seule correction, mais pour une faille WordPress critique : la vulnérabilité CVE-2026-87902, notée 9,2 sur 10, se trouve dans le cœur de WordPress lui-même, pas dans une extension (plugin). Quelques heures plus tard, des attaques étaient déjà observées. Le lendemain, les attaquants ne se contentaient plus de tester les sites : ils écrivaient des fichiers sur les serveurs.
La plupart des articles s'arrêtent à « mettez à jour ». Le conseil est juste, mais il laisse de côté une idée reçue : « mon WordPress se met à jour tout seul, donc je suis protégé ». C'est souvent vrai. Pas toujours. Voici comment savoir en deux minutes dans quel cas se trouve votre site, et quoi faire s'il n'est pas du bon côté.
Ce que permet cette faille WordPress, sans jargon
Pour afficher une page, WordPress choisit un « modèle » (template) dans les fichiers de votre thème. La faille permet à un attaquant, sans compte ni mot de passe, de détourner ce choix : au lieu d'un fichier du thème, WordPress charge un autre fichier PHP présent sur le serveur, choisi par l'attaquant, et exécute son code. Les spécialistes appellent cela une traversée de répertoire (path traversal) menant à une inclusion de fichier local.
L'équipe de sécurité de WordPress précise que cela peut conduire à une exécution de code à distance « sous certaines conditions ». Autrement dit, la prise de contrôle complète du site (et l'accès à ses données) n'est pas automatique sur tous les sites WordPress. Selon l'analyse publiée par BleepingComputer, il faut notamment que le thème actif contienne un dossier dont le nom commence par « page- » et que le serveur expose un fichier exploitable. Le cas observé passe par pearcmd.php, un utilitaire PHP présent sur de nombreux serveurs, lorsque le réglage PHP register_argc_argv est activé. Des configurations très répandues sont citées : l'image Docker officielle de PHP et cPanel par défaut avec PHP antérieur à 8.5.
Ne vous rassurez pas trop vite avec ces conditions. Vous ne savez probablement pas, de tête, comment votre hébergeur a configuré PHP, ni quels dossiers contient votre thème. Et un attaquant n'a pas besoin de le savoir non plus : ses robots testent, et il suffit que ça marche.
| Élément | Ce qu'il faut retenir |
|---|
| Référence | CVE-2026-87902, gravité 9,2 / 10 |
| Où | Cœur de WordPress (fichier wp-includes/template.php), pas une extension |
| Qui peut l'exploiter | N'importe qui, sans compte, à distance |
| Versions touchées | 4.7.0 à 7.1.1 |
| Correctif | 7.1.2, publié le 22/09/2026, et versions corrigées pour 24 branches plus anciennes (7.0 à 4.7) |
| Exploitation | Observée dès le 22/09 par Patchstack, écriture de fichiers sur les serveurs le 23/09 |
Une exploitation en quelques heures, à partir du correctif
La chronologie est la partie la plus instructive. Patchstack, un éditeur de sécurité spécialisé dans WordPress, a observé les premières requêtes malveillantes moins de cinq heures après la publication du correctif, selon BleepingComputer (les sources divergent de quelques heures sur le premier signal, pas sur le fond). Les premiers essais se contentaient de charger des fichiers inoffensifs de WordPress pour repérer les sites vulnérables. Le 23 septembre, le trafic d'attaque avait été multiplié par plus de dix, et les attaquants déposaient des fichiers PHP dans les dossiers temporaires des serveurs (/tmp, /var/tmp).
Patchstack note un détail qui change la lecture du risque : les attaquants ont, selon toute vraisemblance, construit leur attaque en étudiant la correction elle-même. C'est un schéma classique. La publication d'un correctif révèle l'endroit exact du problème. À partir de ce moment, la vulnérabilité est connue de tous et chaque site WordPress non mis à jour est une cible documentée, que des robots repèrent en masse. Le délai confortable de « je verrai ça la semaine prochaine » n'existe plus.
« Mon site se met à jour tout seul » : vrai, sauf quand c'est faux
WordPress installe automatiquement ses mises à jour mineures et de sécurité depuis la version 3.7. La documentation officielle indique que ces mises à jour automatiques sont actives « sur la plupart des sites ». Si c'est votre cas, votre site a probablement déjà reçu la 7.1.2, ou la version corrigée de sa branche. Probablement. Voici les situations où ce n'est pas le cas.
1. Les mises à jour automatiques ont été désactivées
Deux réglages, placés dans le fichier de configuration wp-config.php, coupent ce mécanisme : AUTOMATIC_UPDATER_DISABLED (qui désactive tout, une pratique que la documentation WordPress qualifie de « fortement déconseillée ») et WP_AUTO_UPDATE_CORE réglé sur false. Ils sont souvent ajoutés par un prestataire, avec une intention raisonnable : éviter qu'une mise à jour ne casse une extension ou un thème personnalisé. Sauf que la contrepartie de ce choix, c'est que quelqu'un doit appliquer les correctifs à la main. Si personne n'en a la charge, le site reste figé.
2. Le site est « figé » par son prestataire ou son hébergeur
Certains sites ont été livrés puis laissés en l'état, parfois avec un thème lourdement modifié que personne n'ose mettre à jour. D'autres sont gérés par un hébergeur qui pilote lui-même les versions, à son rythme. Dans les deux cas, la vraie question n'est pas technique : qui, nommément, est responsable d'appliquer ce correctif ? Nous avons détaillé les trois configurations possibles dans notre article « Qui met à jour mon site ? ».
3. Le site tourne sur une version très ancienne
WordPress a publié des corrections pour toutes les branches depuis la 4.7. Les versions 4.6 et antérieures ne reçoivent plus aucun correctif de sécurité. Et même pour les branches corrigées, WordPress le rappelle clairement : seule la version la plus récente est activement maintenue. Les corrections des anciennes branches sont un geste de courtoisie, pas une garantie pour la suite.
4. La mise à jour a échoué en silence
Une mise à jour automatique peut échouer (droits sur les fichiers, espace disque, blocage côté serveur). WordPress envoie en principe un e-mail à l'adresse de l'administrateur. Si cette adresse est celle d'un ancien salarié ou d'une agence avec laquelle vous ne travaillez plus, personne ne l'a lu.
Vérifier votre version en deux minutes
Pas besoin d'être développeur. Connectez-vous à l'administration de votre site (généralement votresite.re/wp-admin) puis regardez l'un de ces trois endroits :
- En bas à droite de n'importe quelle page de l'administration : la mention « Version x.y.z » s'affiche.
- Tableau de bord, puis Mises à jour : WordPress indique la version installée et propose la mise à jour si elle manque.
- Outils, puis Santé du site, onglet Infos : la version exacte figure dans la section WordPress.
Comparez ensuite avec ce tableau. Votre site est protégé contre cette faille si sa version est égale ou supérieure à la version corrigée de sa branche.
| Votre branche | Version corrigée minimale |
|---|
| 7.1 | 7.1.2 |
| 7.0 | 7.0.6 |
| 6.9 | 6.9.9 |
| 6.8 | 6.8.10 |
| 6.7 | 6.7.9 |
| 6.6 | 6.6.9 |
| 6.5 | 6.5.12 |
| 6.4 | 6.4.12 |
| 6.3 | 6.3.12 |
| 6.2 | 6.2.13 |
| 6.1 | 6.1.14 |
| 6.0 | 6.0.16 |
| 5.0 à 5.9 | voir la liste complète sur wordpress.org (de 5.0.29 à 5.9.18) |
| 4.7 à 4.9 | 4.7.37, 4.8.32, 4.9.33 |
| 4.6 et antérieures | aucun correctif : migration indispensable |
Si votre site est sur une branche 5.x ou 4.x, la faille du jour n'est pas votre seul problème. Un site qui n'a pas changé de branche majeure depuis des années cumule généralement d'autres retards, à commencer par ses extensions. C'est le sujet de notre article sur les failles critiques d'extensions WordPress de fin août, qui propose une checklist dédiée.
Si le site n'était pas à jour : mettre à jour ne suffit pas
Si votre site affichait une version vulnérable après le 22 septembre, appliquez la mise à jour immédiatement (Tableau de bord, puis Mises à jour, puis « Mettre à jour maintenant »), après une sauvegarde si vous en avez la possibilité. Mais gardez en tête qu'une mise à jour ferme la porte ; elle ne fait pas sortir quelqu'un qui serait déjà entré.
Demandez donc à votre hébergeur ou à votre prestataire de vérifier trois choses, qu'il saura interpréter :
- Les dossiers temporaires du serveur (
/tmp, /var/tmp) : des fichiers PHP inattendus y ont été déposés lors des attaques observées. Les noms relevés par BleepingComputer incluent wp-pear-rce-flag.php, poc87902.php, ou des fichiers commençant par luci_ et zeta_.
- Les journaux d'accès du serveur : des requêtes contenant des séquences de traversée de répertoire encodées dans le paramètre
pagename, associées à un page_id valide.
- La présence de
pearcmd.php et le réglage register_argc_argv dans la configuration PHP, qui conditionnent la voie d'attaque observée.
Si l'un de ces contrôles révèle une anomalie, ne vous contentez pas de supprimer le fichier suspect. Un site compromis doit être examiné entièrement : comptes administrateurs ajoutés, fichiers modifiés, redirections cachées. C'est un travail de spécialiste, à confier sans attendre.
WordPress n'est pas le problème, l'absence de responsable l'est
Il serait facile d'en conclure que WordPress est dangereux. Ce serait injuste. L'équipe de sécurité a corrigé la faille, rétroporté la correction sur 24 branches plus anciennes et publié l'information de façon transparente. Le correctif existait avant les premières attaques.
Le vrai risque est ailleurs : dans l'écart entre le moment où une correction est disponible et le moment où elle est appliquée sur votre serveur. Cet écart se compte désormais en heures pour les attaquants, et parfois en mois pour les sites sans responsable identifié. Un site web est un logiciel vivant, avec des composants qui reçoivent des correctifs tous les mois, comme nous l'expliquions dans notre article sur les mises à jour de sécurité mensuelles. La question n'est pas « WordPress ou pas », c'est « qui surveille, et en combien de temps il agit ».
C'est aussi pour cette raison que chez Axiom, sur les projets de sites vitrines sur mesure, la maintenance et la surveillance des dépendances font partie de la conversation dès le devis, pas après le premier incident. Et quand un site WordPress ancien accumule trop de dette, la question d'une migration vers une base plus simple à maintenir mérite d'être posée calmement, chiffres à l'appui.
En résumé
- La faille CVE-2026-87902 touche le cœur de WordPress, de la 4.7.0 à la 7.1.1, et elle est exploitée depuis le jour même du correctif.
- Les mises à jour automatiques protègent la plupart des sites, mais pas ceux où elles sont désactivées, figées, trop anciennes ou en échec silencieux.
- Vérifiez votre version en deux minutes (bas de page de l'administration) et comparez-la au tableau ci-dessus.
- Si le site était vulnérable après le 22 septembre, faites vérifier les traces d'intrusion : la mise à jour seule ne suffit pas.
Vous ne savez pas qui met à jour votre site, ni s'il a été touché ? Notre équipe, basée à La Réunion, peut regarder avec vous l'état réel de votre installation. Demandez un audit gratuit ou contactez-nous : vous saurez où vous en êtes, sans jargon ni engagement. Pour découvrir notre approche, consultez notre page agence web à La Réunion.
Sources
