Le correctif de WordPress est devenu la carte des attaquants : première attaque en quelques heures, plus de 30 000 IP en cinq jours

Le 22 septembre 2026, veille du congé de la Fête nationale, WordPress a publié la mise à jour de sécurité 7.1.2 pour corriger la CVE-2026-87902. La faille ne se trouve ni dans une extension ni dans un thème. Elle se trouve dans le cœur de WordPress, et elle touche toutes les versions de 4.7.0 à 7.1.1. Le jour même, à 11:49 UTC (14 h 49, heure de Riyad), la société de sécurité Patchstack a observé la première tentative d'exploitation, et moins de quatre heures plus tard, la première tentative d'écriture d'un fichier sur le serveur d'un site.

Comment l'attaque s'est propagée en cinq jours

Puis elle s'est propagée. Selon le rapport de CrowdSec publié aujourd'hui, 28 septembre, son réseau a enregistré 322 680 signaux d'attaque correspondant à la faille, provenant de 30 813 adresses IP distinctes, entre le 23 et le 27 septembre, avec un pic le 27 septembre à 124 154 signaux. L'Autorité nationale de cybersécurité (NCA) d'Arabie saoudite a émis une alerte de niveau critique, n° 2026-7873, le 23 septembre, et l'agence américaine CISA a ajouté la faille à son catalogue des vulnérabilités exploitées connues le 25 septembre.

Ce que fait la faille, en termes simples

Quand un visiteur demande une page, WordPress détermine quel fichier de modèle du thème utiliser pour l'afficher. Le bogue se situe à cette étape : un attaquant non connecté peut l'orienter vers un fichier PHP présent sur le serveur en dehors du dossier du thème, et WordPress l'exécutera. WordPress évalue la gravité de la faille à 9,2 sur 10 ; la CISA l'évalue à 8,1.

Elle se transforme en prise de contrôle du site lorsque les conditions citées dans l'avis de WordPress et dans les rapports des chercheurs sont réunies :

• Le thème : le thème actif contient un dossier dont le nom commence par page-. L'avis cite Twenty Twelve, Twenty Fourteen, Neve, Hestia et Sydney parmi les thèmes concernés.
• Un réglage PHP : register_argc_argv est activé, ce qui, selon CrowdSec, est le réglage par défaut dans les images Docker officielles de PHP et sur les serveurs cPanel exécutant une version de PHP antérieure à 8.5.
• Un fichier auxiliaire : le fichier pearcmd.php de PEAR est présent sur le serveur. Les attaquants s'en servent pour écrire de nouveaux fichiers PHP, autrement dit une porte dérobée qui survit à la mise à jour.

La faille ne frappe donc pas tous les sites de la même façon, mais Security Affairs le résume ainsi : l'exécution de code nécessite que la configuration du serveur s'y prête, et beaucoup de serveurs s'y prêtent. Un chef d'entreprise ne sait généralement pas quel thème est actif ni comment le serveur est configuré : l'hypothèse prudente est donc que le site est exposé jusqu'à preuve du contraire.

Pourquoi l'attaque est arrivée en quelques heures, et non en quelques semaines

Une mise à jour de sécurité révèle par nature l'emplacement du bogue, puisque la modification du code est publique. Patchstack indique que les premières charges malveillantes correspondaient exactement au schéma que le correctif a comblé, ce qui signifie que leurs auteurs sont partis du correctif lui-même plutôt que d'une découverte indépendante. Les premières tentatives demandaient des fichiers ordinaires du cœur de WordPress, comme wp-login.php et wp-cron.php, pour observer la réaction des sites, puis sont passées à l'écriture de fichiers.

Le trafic porte aussi les empreintes de scanners automatisés et de codes de preuve de concept publiés. Pour un chef d'entreprise, cela signifie que personne ne choisit votre site en particulier. Les outils balaient tous les sites WordPress qu'ils peuvent atteindre, et la différence entre un site compromis et un site sain tient au fait que la mise à jour soit arrivée avant eux ou non.

Votre site se met-il à jour tout seul ?

Probablement, mais ne le supposez pas. WordPress propose des mises à jour automatiques en arrière-plan depuis la version 3.7, et depuis la 5.6, les nouvelles installations se mettent à jour automatiquement pour les versions mineures comme majeures. L'annonce de la 7.1.2 indique que les sites qui prennent en charge les mises à jour automatiques en arrière-plan commenceront à se mettre à jour automatiquement.

Mais les mises à jour automatiques peuvent être désactivées par une seule ligne dans wp-config.php. Certains développeurs les désactivent volontairement pour qu'une mise à jour ne casse pas un thème personnalisé, et certains hébergeurs gèrent les mises à jour de leur côté. Un site construit il y a des années par un indépendant, dont le contrat a pris fin depuis, peut rester sur une ancienne version sans que personne ne s'en aperçoive. Pour vérifier :

• Connectez-vous à l'administration du site, ouvrez la page Mises à jour dans le menu Tableau de bord, et vous y verrez la version actuelle.
• La version sûre est la 7.1.2 ou une version ultérieure. Si votre site tourne sur une branche plus ancienne, le correctif a été appliqué à toutes les branches jusqu'à la 4.7, notamment 7.0.6, 6.9.9, 6.8.10 et 4.7.37 ; la liste complète figure dans l'avis de WordPress cité dans les sources.
• Notez que WordPress indique que seule la version la plus récente bénéficie d'un support actif. Un site laissé sur une ancienne branche a reçu ce correctif, mais il vit en sursis. Nous avons présenté ce que la nouvelle version apporte à un site d'entreprise dans WordPress 7.1 : les principales nouveautés.

Elementor aussi : un seul lien suffit

La même semaine, Elementor, le constructeur de pages populaire de WordPress, a corrigé une faille présente uniquement dans les versions 4.3.0 et 4.3.1. Si un administrateur du site ouvre un lien piégé alors qu'il est connecté, un attaquant peut créer un compte administrateur qu'il contrôle, et le lien peut arriver par e-mail, par messagerie ou dans un commentaire. Selon BleepingComputer, ces versions tournent sur près de 2 millions de sites. Le correctif est sorti dans la version 4.3.2 le 24 septembre, et le site ne signalait aucune exploitation active au moment de sa publication.

Assurez-vous qu'Elementor est en version 4.3.2 ou ultérieure, et faites-en une règle d'équipe : n'ouvrez pas de liens provenant de messages ou de commentaires lorsque vous êtes connecté à l'administration du site.

Si votre site n'a pas été mis à jour depuis le 22 septembre

• Mettez-le à jour maintenant : si le développeur craint que la mise à jour ne casse quelque chose, Patchstack indique que la voie d'attaque peut être fermée temporairement en bloquant les tentatives de traversée de répertoires dans le paramètre pagename, ou en désactivant register_argc_argv. C'est le travail de l'hébergeur ou du développeur, et cela ne remplace pas la mise à jour.
• Partez du principe que votre site a été sondé : demandez au développeur ou à l'hébergeur de rechercher des fichiers PHP que personne n'a ajoutés, en particulier dans /tmp et /var/tmp, où Patchstack cite des fichiers comme poc87902.php et wp-pear-rce-flag.php comme signes d'une exécution de code réussie.
• Si quelque chose apparaît : traitez-le comme un incident, pas comme une mise à jour. Changez les mots de passe des comptes administrateurs, de la base de données et de l'hébergement, restaurez le site à partir d'une sauvegarde saine, puis mettez-le à jour.
• Si le site contient des données clients : commandes de boutique, formulaires de contact ou comptes, le guide de la SDAIA sur les incidents de violation de données personnelles impose au responsable du traitement d'informer l'autorité compétente dans les 72 heures suivant la découverte d'une violation susceptible de nuire aux données ou aux personnes concernées.

Le regard d'Origami

De nombreux sites d'entreprise sont construits sur WordPress puis traités comme une brochure imprimée : le développeur le livre, le propriétaire paie, et personne ne demande qui le tiendra à jour. Cette faille rappelle qu'un site web est un système vivant, hébergé sur un serveur exposé à Internet, et que l'intervalle entre la publication d'un correctif et l'arrivée d'un attaquant se mesure désormais en heures. La vraie question n'est pas de savoir si WordPress est sûr, puisqu'il a corrigé le bogue et déployé le correctif sur toutes les branches jusqu'à la 4.7. Elle est de savoir qui, dans votre entreprise, est chargé de l'installer.

C'est pourquoi nous pensons qu'un contrat de maintenance de site web doit fixer un délai maximal pour installer les mises à jour de sécurité critiques, exiger une copie de préproduction où les mises à jour sont testées avant le site en ligne, et prévoir des sauvegardes régulières conservées hors du serveur lui-même. Et si les mises à jour sont sans cesse reportées parce que le thème est personnalisé d'une manière qui casse à chaque mise à jour, c'est un problème de construction du site, pas de WordPress, et il mérite d'être corrigé avant la prochaine faille.

L'essentiel : trois étapes

• Aujourd'hui : ouvrez l'administration et vérifiez que la version est la 7.1.2 ou la version corrigée de votre branche, et qu'Elementor est en version 4.3.2 ou ultérieure.
• Cette semaine : demandez au développeur ou à l'hébergeur d'analyser le serveur à la recherche de fichiers PHP inconnus et de confirmer par écrit que les mises à jour automatiques sont activées.
• Ce mois-ci : ajoutez au contrat de maintenance un délai maximal d'installation des mises à jour de sécurité, et désignez la personne qui en est responsable.

Sources

• WordPress : version de sécurité WordPress 7.1.2 (22 septembre 2026)
• WordPress : avis de sécurité GHSA-7hp8-65ch-5whp, versions touchées et corrigées, conditions d'exploitation
• Autorité nationale de cybersécurité (NCA) : alerte WordPress n° 2026-7873 (23 septembre 2026)
• CISA : la CVE-2026-87902 ajoutée au catalogue Known Exploited Vulnerabilities (25 septembre 2026)
• Patchstack : les attaquants ont commencé à sonder les sites WordPress quelques heures après le correctif
• CrowdSec : rapport d'exploitation de la CVE-2026-87902 (28 septembre 2026)
• Security Affairs : les conditions d'exécution de code via la CVE-2026-87902
• BleepingComputer : une faille d'Elementor permet aux attaquants de créer des comptes administrateurs
• WordPress : documentation sur les mises à jour automatiques en arrière-plan et la manière de les désactiver
• SDAIA : guide procédural relatif aux incidents de violation de données personnelles