Les utilisateurs de WordPress font face à une nouvelle vague d’exploitation visant une vulnérabilité du processus de mise à jour du noyau. Selon les données communiquées par Wordfence, plus de 240 000 tentatives d’exploitation de la faille CVE-2026-119977 ont été bloquées depuis le début de la campagne, le 28 octobre 2026.
Cette vulnérabilité permet, dans certaines conditions, à un attaquant non authentifié de tenter une exécution de code à distance pendant la mise à jour du noyau WordPress. Le problème repose sur une condition de concurrence (race condition) qui expose temporairement des fichiers d’installation dans un répertoire accessible depuis le Web.
La situation est d’autant plus préoccupante que les attaques ont commencé le jour même de la publication du correctif. Wordfence indique que son pare-feu a enregistré une forte activité entre le 29 octobre et le 1er novembre, avec un pic de plus de 74 000 tentatives bloquées le 30 octobre.
Une faille RCE liée au processus de mise à jour de WordPress
CVE-2026-119977 concerne le mécanisme utilisé par WordPress pour effectuer certaines mises à jour complètes du noyau.
Le problème provient de la manière dont les fichiers de la nouvelle version sont temporairement extraits dans le répertoire d’upgrade. Avant la correction, ces fichiers pouvaient se retrouver dans des emplacements prévisibles et accessibles depuis le Web.
L’advisory officiel publié dans le dépôt de développement de WordPress décrit une condition de concurrence de type TOCTOU (Time-of-check to Time-of-use). Lorsqu’une mise à jour est en cours, un attaquant peut tenter de gagner la course entre la création des fichiers temporaires et leur suppression à la fin du processus.
Le risque est particulièrement sérieux car cette attaque ne nécessite pas de disposer préalablement d’un compte WordPress.
Comment fonctionne l’attaque ?
Lorsqu’une mise à jour complète du noyau est lancée, WordPress place temporairement les fichiers nécessaires à l’opération dans son espace d’upgrade.
Avant le correctif, certains chemins étaient suffisamment prévisibles pour qu’un attaquant puisse tenter d’accéder aux fichiers d’installation pendant cette courte période.
Les requêtes observées par les chercheurs ciblent notamment des chemins situés sous :
/wp-content/upgrade/
Des tentatives ont notamment visé des fichiers d’installation tels que setup-config.php.
Le principe est donc de profiter de la très courte fenêtre pendant laquelle les fichiers de mise à jour sont présents et accessibles. Si la chaîne d’exploitation aboutit, l’attaquant peut potentiellement atteindre une exécution de code sur le serveur et compromettre le site.
Wordfence précise cependant qu’un grand nombre de requêtes bloquées ne signifie pas qu’un nombre équivalent de sites ont été compromis. Les 240 000 événements correspondent à des tentatives détectées et bloquées, et non à 240 000 compromissions réussies.
Plus de 240 000 tentatives d’exploitation détectées
La télémétrie de Wordfence montre que les attaques ont commencé le 28 octobre 2026, date à laquelle le correctif WordPress a été publié.
L’activité s’est ensuite intensifiée. Selon les données rapportées par Wordfence, la période comprise entre le 29 octobre et le 1er novembre a concentré l’essentiel des tentatives, avec un sommet de plus de 74 000 requêtes bloquées le 30 octobre.
Cette chronologie illustre une tendance désormais classique dans la sécurité des applications Web : dès qu’une vulnérabilité exploitable publiquement est corrigée, les systèmes automatisés commencent rapidement à rechercher les installations qui n’ont pas encore appliqué le correctif.
Il faut donc distinguer deux éléments : la présence d’une activité d’exploitation réelle et la réussite d’une attaque. Les données disponibles confirment une forte activité de balayage et de tentative d’exploitation, mais elles ne permettent pas d’affirmer que les 240 000 requêtes ont conduit à des intrusions.
WordPress 4.7 à 7.1.3 concernés
CVE-2026-119977 touche un large éventail de branches de WordPress.
L’advisory du projet WordPress recense comme versions vulnérables les branches allant de 4.7.0 à 7.1.3. Les versions corrigées commencent notamment par 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11 et se poursuivent avec des correctifs rétroportés jusqu’à la branche 4.7.
Cela signifie que les administrateurs ne doivent pas simplement vérifier si leur installation utilise une version récente de WordPress : les anciennes branches bénéficiant encore de correctifs de sécurité disposent elles aussi de versions corrigées spécifiques.
Le référentiel officiel des versions WordPress permet de vérifier les versions disponibles et les branches concernées.
Une vulnérabilité évaluée à 8,1 sur 10
CVE-2026-119977 est associée à un score CVSS v3.1 de 8,1 sur 10, soit une sévérité élevée.
Le vecteur CVSS indique notamment :
- attaque réalisable à distance ;
- aucun privilège préalable requis ;
- aucune interaction utilisateur nécessaire ;
- impact élevé potentiel sur la confidentialité ;
- impact élevé sur l’intégrité ;
- impact élevé sur la disponibilité ;
- complexité d’exploitation élevée en raison de la fenêtre de concurrence.
La complexité élevée est importante : l’attaquant doit réussir à intervenir au moment précis où le processus de mise à jour laisse les fichiers temporaires accessibles. La vulnérabilité est donc sérieuse, mais son exploitation dépend d’une fenêtre temporelle particulièrement courte.
WordPress 7.1.4 corrige la vulnérabilité
Le projet WordPress a publié WordPress 7.1.4 le 28 octobre 2026 dans le cadre d’une mise à jour de sécurité.
La publication officielle confirme que cette version corrige notamment une faiblesse du processus de mise à jour susceptible de conduire à une exécution de code à distance pendant la fenêtre d’upgrade. WordPress recommande explicitement aux administrateurs d’appliquer cette mise à jour immédiatement.
Le correctif a également été rétroporté vers les branches encore éligibles aux mises à jour de sécurité, jusqu’à WordPress 4.7.
Les utilisateurs doivent donc installer WordPress 7.1.4 ou la version corrigée correspondant à leur branche, plutôt que de rester sur 7.1.3 ou une version antérieure.
La correction modifie le mécanisme de staging
Le correctif ne consiste pas simplement à modifier une permission.
WordPress a renforcé le fonctionnement de son répertoire temporaire utilisé pendant les mises à jour afin de réduire la possibilité pour un attaquant de prédire et d’atteindre les fichiers d’installation pendant la fenêtre d’upgrade.
Les informations techniques publiées autour de la version 7.1.4 font notamment état d’améliorations liées à la gestion du répertoire de staging et à la protection des données de configuration temporaires.
L’objectif est de fermer la course entre l’extraction des fichiers et leur utilisation malveillante.
Le bulletin officiel de WordPress consacré à la version 7.1.4 constitue la référence à privilégier pour vérifier le correctif appliqué.
Pourquoi les mises à jour WordPress sont particulièrement ciblées
WordPress constitue une cible particulièrement intéressante pour les campagnes automatisées en raison du nombre considérable de sites qui l’utilisent.
Une vulnérabilité affectant le noyau peut potentiellement toucher des installations très différentes : sites institutionnels, boutiques en ligne, médias, blogs, sites d’entreprises ou portails administratifs.
Dans le cas présent, le problème est encore plus sensible parce que l’attaque ne dépend pas d’une extension ou d’un thème particulier. Elle vise directement le mécanisme de mise à jour du WordPress Core.
Les attaquants peuvent ainsi rechercher automatiquement des serveurs dont la version n’a pas encore été corrigée.
Que doivent faire les administrateurs WordPress ?
La priorité est de vérifier immédiatement la version du noyau installée.
1. Mettre WordPress à jour
Les sites utilisant WordPress 7.1.3 ou une version antérieure doivent passer à 7.1.4 ou à la version corrigée de leur branche.
WordPress recommande d’effectuer les mises à jour de sécurité sans attendre.
2. Vérifier les branches anciennes
Un site utilisant une branche 6.x ou 5.x ne doit pas être considéré comme automatiquement protégé.
Les correctifs ont été rétroportés vers plusieurs branches. Il faut donc vérifier la version corrective correspondant exactement à la branche utilisée.
L’archive officielle des versions WordPress permet de contrôler les versions disponibles.
3. Examiner les journaux après une exposition
Les administrateurs qui n’ont pas appliqué le correctif depuis le 28 octobre doivent envisager une analyse des journaux Web et des événements de sécurité.
Il convient notamment de rechercher des requêtes inhabituelles visant le répertoire :
/wp-content/upgrade/
et des fichiers d’installation tels que setup-config.php.
Une activité suspecte pendant une mise à jour peut justifier une investigation plus poussée du système de fichiers, de la base de données et des comptes administrateurs.
4. Rechercher d’éventuelles modifications non autorisées
En cas d’exposition à une tentative d’exploitation, les équipes de sécurité devraient également vérifier les éléments sensibles du site : fichiers PHP récemment créés ou modifiés, comptes administrateurs inattendus, modifications de la configuration, extensions inconnues et connexions sortantes inhabituelles.
Il ne faut toutefois pas considérer une requête bloquée comme une preuve de compromission.
Une vulnérabilité désormais activement ciblée
Le principal enseignement de cette campagne est la rapidité avec laquelle les attaquants ont commencé à rechercher des systèmes vulnérables.
Wordfence indique que les premières tentatives sont apparues le jour même de la publication du correctif. Le volume dépassant désormais 240 000 tentatives montre que les systèmes automatisés surveillent étroitement les nouvelles vulnérabilités du noyau WordPress.
La situation rappelle également qu’une mise à jour de sécurité ne doit pas être considérée comme une simple opération de maintenance. Lorsqu’une vulnérabilité est publiquement documentée et qu’une exploitation est observée, chaque installation non corrigée devient une cible potentielle.
Conclusion
CVE-2026-119977 représente une menace sérieuse pour les installations WordPress qui n’ont pas encore été mises à jour. La vulnérabilité exploite une condition de concurrence dans le processus de mise à jour du noyau et peut, dans certaines conditions, permettre à un attaquant non authentifié d’atteindre une exécution de code à distance.
Plus de 240 000 tentatives d’exploitation ont déjà été bloquées par Wordfence, avec une activité particulièrement importante dans les jours suivant la publication du correctif. Ces chiffres ne constituent pas un bilan de compromissions, mais ils confirment que la faille est activement recherchée.
La réponse la plus importante reste donc simple : mettre WordPress à jour vers 7.1.4 ou vers la version corrective correspondant à sa branche, puis contrôler les journaux et l’intégrité du site lorsqu’une installation est restée exposée après le 28 octobre 2026.
Les informations officielles de WordPress et l’advisory technique du projet constituent les références à privilégier pour vérifier l’état du correctif.
SOURCE : GBHACKERS
