Le 23 septembre 2026, le Centre canadien pour la cybersécurité a publié le bulletin AV26-952 au sujet d’une vulnérabilité critique dans le cœur de WordPress, en précisant qu’elle était déjà « exploitée dans la nature ».
Nos serveurs ont été corrigés tôt le matin du 25 septembre. Voici ce qu’il faut savoir, et ce que vous devriez vérifier de votre côté.
De quoi s’agit-il
La faille porte l’identifiant CVE-2026-87902. Elle se situe dans la fonction qui choisit le gabarit d’affichage d’une page, au cœur même de WordPress — donc pas dans une extension ou un thème en particulier. Elle permet à un visiteur non authentifié, c’est-à-dire n’importe qui, de faire charger au site un fichier PHP qui ne lui appartient pas, et d’aboutir dans certaines conditions à l’exécution de code sur le serveur.
Le correctif officiel a été publié le 22 septembre. Les premières exploitations automatisées ont été observées dès le lendemain, à l’échelle d’Internet. C’est le rythme d’aujourd’hui : entre la publication d’un correctif et les premières attaques de masse, on compte en heures. Il y a quelques années, on comptait en semaines.
Quelles versions sont touchées
Toutes les versions de WordPress antérieures à la 7.1.2. WordPress a publié un correctif pour chaque branche encore suivie : les versions saines sont les 7.1.2, 7.0.6, 6.9.9 et 6.8.10, ainsi que les correctifs équivalents des branches plus anciennes — la 6.7.9, par exemple.
Autrement dit : votre numéro de version ne suffit pas à vous rassurer. Un site en 6.8.10 est à jour, un site en 7.0.5 ne l’est pas. Le plus simple est d’ouvrir votre tableau de bord WordPress, section Tableau de bord → Mises à jour : si une mise à jour de WordPress y est proposée, appliquez-la.
Ce que nous avons fait sur nos serveurs
Plutôt que d’attendre que chaque site soit mis à jour par son propriétaire, nous avons pris les devants.
- Nous avons passé en revue l’ensemble de nos serveurs, site par site, pour repérer ceux à qui le correctif manquait.
- Le correctif officiel de WordPress a été appliqué partout où il était absent. Chaque fichier a été sauvegardé avant modification, puis vérifié après — aucun site n’a été interrompu.
- Nous avons désactivé, au niveau du serveur, le composant PHP dont cette attaque a besoin pour aboutir. C’est la partie la plus utile sur le long terme : même un site qui prendrait du retard dans ses mises à jour ne peut plus être exploité par ce chemin.
- Une trentaine d’adresses IP à l’origine de ces campagnes d’exploitation ont été bloquées, simultanément sur tous nos serveurs — pas seulement là où elles s’étaient manifestées.
- Nous avons déposé une plainte pour abus auprès de chacun des neuf fournisseurs d’où provenaient ces adresses — dont plusieurs grands acteurs de l’infonuagique —, journaux à l’appui. C’est une démarche que nous faisons systématiquement : tant que ces machines restent en ligne, elles servent à attaquer les sites de tout le monde, pas seulement les nôtres.
Le correctif que nous avons appliqué est celui de WordPress lui-même, à l’identique. Il sera simplement remplacé par la prochaine mise à jour officielle, sans conflit ni manipulation de votre part.
Ce que vous devriez faire
Le Centre canadien pour la cybersécurité recommande d’installer les mises à jour « dès qu’elles sont disponibles ». Dans les faits, une seule habitude fait la différence : activez les mises à jour automatiques de WordPress. C’est ce qui protège un site dans les heures qui suivent la publication d’un correctif, sans dépendre d’une intervention manuelle — la vôtre, celle de votre agence ou la nôtre.
Rappelons le partage habituel : la sécurité du serveur relève de l’hébergeur, la mise à jour de WordPress, du thème et des extensions relève du propriétaire du site ou de son agence web. Une intervention comme celle-ci reste exceptionnelle : elle se justifiait par la gravité de la faille et la vitesse des attaques, mais un correctif appliqué de l’extérieur ne remplacera jamais un site tenu à jour.
Si vous êtes client chez nous et que vous avez des questions sur l’état de votre site, écrivez-nous.