Une brève période 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 exploitées connues le 3 novembre, selon le Centre canadien pour la cybersécurité. La faille touche les versions non corrigées des branches de WordPress allant de 4.7 à 7.1.3 ; les branches plus anciennes qui disposent du correctif rétroporté correspondant en sont protégées.
Les administrateurs doivent terminer 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 de gravité élevée, notée 8,1 selon le score CVSS, concerne des chemins de préparation prévisibles et accessibles depuis le Web, créés lors des mises à niveau complètes du noyau. Les attaquants qui atteignaient les fichiers temporaires de l’installeur au bon moment pouvaient exécuter du code sur le serveur. Wordfence indique que cette fenêtre ne durait généralement que quelques secondes lors des tests en laboratoire, mais que les attaquants interrogeaient les chemins à répétition pour la détecter.
« Ce qui ressort, c’est l’emplacement de cette faille : elle se trouve 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 à une exécution de code sans authentification. La mise à jour d’un plugin ne corrige pas le noyau, et la mise à jour du noyau ne résout pas toutes les vulnérabilités des composants.
Quelles versions de WordPress contiennent 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.
Les correctifs ont également été intégrés aux branches plus anciennes. Wordfence répertorie 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’un support actif.
Les organisations doivent donner la priorité à ce correctif, car la CISA a identifié la 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 noyau et la personne ou le prestataire responsable des mises à jour. Confirmez que les mises à jour automatiques se sont bien terminées.
Puisque l’exposition se produit pendant une mise à niveau, demandez à l’équipe responsable du serveur ou de l’hébergement de restreindre, lorsque cela 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 seul ne suffit pas à établir que la pile d’hébergement est sécurisée.
Bayram, chercheur en sécurité chez Picus Security, a déclaré que les défenseurs devaient tester les protections lorsque leur niveau d’exposition évolue.
« C’est pourquoi la validation ne peut plus attendre le prochain test programmé. 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 intermédiaires situés sous wp-content/upgrade, en particulier 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, et une requête suspecte ne constitue pas à elle seule une preuve de compromission.
Si les éléments recueillis laissent penser à une intrusion, préservez les journaux et faites intervenir des spécialistes de la réponse à incident 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 à incident, consignez le correctif installé, les résultats de l’enquête et toute lacune dans les éléments disponibles. Les clients d’un hébergement géré doivent demander ces informations à leur fournisseur.
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 dans les applications exposées.