Une courte fenêtre pendant certaines mises à niveau de WordPress peut permettre à des attaquants d’exécuter du code sur le serveur d’un site sans se connecter.
La CISA a ajouté la CVE-2026-119977 à son catalogue des vulnérabilités connues et exploitées le 3 novembre, selon le Centre canadien de la cybersécurité. La faille concerne les versions non corrigées des branches WordPress allant de 4.7 à 7.1.3 ; les anciennes branches qui ont reçu le correctif rétroporté correspondant en sont protégées.
Les administrateurs doivent effectuer la mise à jour en toute sécurité et vérifier si des attaquants ont accédé à leurs sites avant la mise en place de la protection.
Comment la fenêtre de mise à niveau expose les sites WordPress
Cette faille critique, à laquelle le score CVSS de 8,1 a été attribué, concerne des chemins de staging prévisibles et accessibles depuis le Web, créés lors des mises à niveau complètes du cœur. Les attaquants qui atteignaient les fichiers d’installation temporaires au bon moment pouvaient exécuter du code sur le serveur. Selon Wordfence, la fenêtre ne durait généralement que quelques secondes lors des tests en laboratoire, mais les attaquants interrogeaient les chemins à répétition pour la détecter.
« Ce qui ressort, c’est l’endroit où se trouve cette faille : au cœur du processus de mise à niveau, de sorte que l’exposition intervient pendant la même fenêtre de maintenance sur laquelle les équipes comptent pour renforcer leur sécurité », a déclaré Joe Brinkley, directeur de la recherche en sécurité offensive et de la communauté chez Cobalt.
La vulnérabilité est distincte de la faille du plugin Bricksforge qui exposait les sites WordPress à l’exécution de code sans authentification. Mettre à jour un plugin ne corrige pas le cœur, et mettre à jour le cœur ne résout pas toutes les vulnérabilités des composants.
Quelles versions de WordPress intègrent le correctif ?
WordPress a publié la version 7.1.4 le 28 octobre et recommande d’effectuer la mise à jour immédiatement. Le projet attribue à Umut Bayram le signalement de la faille de mise à niveau.
Des correctifs ont également été publiés pour les anciennes branches. Wordfence recense les versions corrigées, notamment 7.0.8, 6.9.11, 6.8.12 et 4.7.39. Les administrateurs doivent vérifier la version corrigée de leur branche plutôt que de supposer que toutes les versions antérieures à 7.1.4 restent vulnérables. WordPress indique que seule sa version la plus récente bénéficie d’une prise en charge active.
Les entreprises doivent donner la priorité à ce correctif, car la CISA a identifié cette vulnérabilité comme étant exploitée dans la nature.
Ce que les administrateurs doivent faire avant de clore l’incident
Commencez par recenser chaque installation WordPress, sa version du cœur et la personne ou le prestataire responsable des mises à jour. Vérifiez que les mises à jour automatiques sont bien terminées.
Comme l’exposition se produit pendant une mise à niveau, demandez à l’équipe responsable du serveur ou de l’hébergement de restreindre, lorsque c’est possible, l’accès public aux répertoires temporaires de mise à niveau. Coordonnez cette protection avec le processus de mise à jour sans retarder l’application du correctif de sécurité.
N’oubliez pas les dépendances : l’ attaque visant le traitement des images HEIC de WordPress montre pourquoi la mise à jour du CMS à elle seule ne suffit pas à garantir la sécurité de la pile d’hébergement.
Bayram, chercheur en sécurité chez Picus Security, a déclaré que les défenseurs devaient tester les protections lorsque leur exposition évolue.
« C’est pourquoi la validation ne peut plus attendre le prochain test planifié. Elle doit commencer dès qu’un changement intervient », a-t-il déclaré.
Dans le cadre de l’enquête, comparez les horodatages récents des mises à niveau avec les journaux Web afin de repérer les requêtes visant les fichiers d’installation placés sous wp-content/upgrade, notamment setup-config.php. Recherchez les comptes administrateur inconnus, les fichiers PHP inattendus, les modifications de configuration et les connexions sortantes inhabituelles. Il s’agit de pistes d’enquête ; une requête suspecte isolée ne prouve pas une compromission.
Si les éléments recueillis laissent penser à une intrusion, préservez les journaux et faites intervenir des spécialistes de la réponse aux incidents avant de supprimer les fichiers suspects. Évaluez si les attaquants ont pu accéder aux identifiants ou aux secrets de l’application et s’il est nécessaire de les remplacer.
La distinction entre la gestion des correctifs et la gestion des vulnérabilités est importante ici : une mise à jour réussie corrige le comportement vulnérable, mais ne prouve pas que l’accès d’un attaquant a été supprimé. Avant de clore la réponse à l’incident, consignez le correctif installé, les résultats de l’enquête et les éventuelles lacunes dans les éléments disponibles. Les clients d’un hébergement géré doivent demander ces informations à leur prestataire.
Pour en savoir plus : découvrez ce que les équipes de sécurité doivent vérifier après les correctifs PHP de Black October, notamment les tentatives d’attaque antérieures, les risques liés à la configuration et l’activation des correctifs sur les applications exposées.