Des attaquants exploitent la faille TOCTOU de WordPress Core pendant les mises à jour

3 novembre 2026. La CISA ajoute CVE-2026-119977 à son catalogue KEV des vulnérabilités exploitées. 28 octobre 2026. WordPress livre la version 7.1.4, qui corrige la faille dans le noyau. 30 octobre 2026. Les premières rafales de requêtes visant les chemins de staging sont déjà observées par les pare-feu. L’affaire tient en une phrase : pendant la fenêtre de mise à jour du noyau, un attaquant peut atteindre l’installeur temporaire avant son nettoyage, et le brancher sur une base de données qu’il contrôle — ce qui ouvre la voie à l’exécution de code sur le serveur.

Pour un exploitant de site, ce n’est pas une histoire de sophistication. C’est une histoire de timing et de volume.

La mécanique de la faille

CVE-2026-119977 est une condition de concurrence de type TOCTOU (time-of-check, time-of-use), classée CWE-367, avec un score CVSS 8.1. Le vecteur d’attaque est non authentifié et ne demande aucune interaction utilisateur, mais il ne se déclenche qu’à un instant précis : pendant une mise à niveau complète du noyau.

Voici le scénario. Lorsque WordPress déploie un paquet de mise à niveau complet, il extrait les fichiers dans un répertoire de staging sous wp-content/upgrade. Sur les installations affectées, ce répertoire est accessible par le web tant que la mise à jour n’est pas terminée. Pendant cette fenêtre — brève, mais réelle — une copie de l’installeur WordPress est exposée publiquement.

Un attaquant qui atteint cet installeur avant la fin du nettoyage peut l’utiliser pour connecter l’installation intermédiaire à une base de données qu’il contrôle. À partir de là, il n’est plus très loin d’exécuter du code côté serveur. Tout le jeu consiste à atteindre les fichiers temporaires avant que WordPress ne les supprime : d’où la course de vitesse, et l’intérêt pour l’attaquant de rejouer les requêtes en boucle.

Le périmètre est large : WordPress Core 4.7 à 7.1.3 sont concernés. Le correctif 7.1.4, publié le 28 octobre 2026, referme la fenêtre. La faille a été signalée par le chercheur Umut Bayram, et Wordfence en est le CNA (CVE Numbering Authority).

Pourquoi cette faille sort du lot

WordPress propulse environ 43 % du web — un volume qui fait de chaque faille du cœur un événement, là où les failles de plugins et de thèmes remplissent l’ordinaire des bulletins. Celle-ci a une particularité supplémentaire : elle ne vit pas dans une fonctionnalité marginale, mais dans le mécanisme de mise à jour lui-même.

Le corollaire est désagréable. Les mises à jour automatiques — qui servent précisément à corriger ce genre de problème — ouvrent la fenêtre dont l’attaquant a besoin. Le temps que le paquet soit extrait dans wp-content/upgrade puis nettoyé, une copie de l’installeur est brièvement accessible. C’est le paradoxe de la faille : le remède crée la surface d’attaque.

Deux conséquences pratiques en découlent. D’abord, un site à jour n’est pas protégé par sa bonne hygiène — la fenêtre s’ouvre au moment même où il se met à jour. Ensuite, la détection doit porter sur les journaux d’accès et le contenu du répertoire de mise à niveau, pas seulement sur la version affichée dans le tableau de bord. La correction 7.1.4 referme la surface à la source : les chemins de staging ne sont plus joignables pendant la mise à niveau, ce qui distingue un vrai correctif d’un contournement par pare-feu.

Ce que disent les chiffres d’exploitation

L’exploitation active est réelle, mais il faut lire les chiffres avec rigueur — la confusion entre requêtes bloquées et sites compromis fausserait votre évaluation du risque.

Le premier chiffre : 18 500 requêtes. D’après Cyber Security News, plus de 18 500 requêtes ont ciblé les chemins d’installeur intermédiaires au cours des 21 premières heures de surveillance. Ces requêtes seules ne prouvent pas qu’une intrusion a réussi ; elles montrent que l’attaque est automatisée et distribuée.

Le second chiffre : 60 471 tentatives bloquées. Un suivi parallèle a compté 60 471 tentatives bloquées sur 24 heures. Wordfence évoque de son côté 12 632 tentatives bloquées en 24 heures. Tous ces nombres mesurent l’activité du pare-feu, pas le nombre de victimes confirmées — deux catégories qu’il faut absolument séparer quand on juge l’ampleur d’une campagne.

Le troisième chiffre : le 6 novembre 2026. La CISA fixe au 6 novembre l’échéance de remédiation pour les agences fédérales civiles américaines, dans le cadre de sa directive contraignante BOD 26-04. C’est la traduction concrète du « priorisez ce correctif » : même sans preuve publique de compromission massive, le statut known exploited change l’ordre de priorité.

Ce qu’il faut faire maintenant

La correction est simple, mais la vérification ne l’est pas. Voici l’ordre d’exécution.

• Passer en 7.1.4. Ouvrez le Tableau de bord → Mises à jour et vérifiez que la version de sécurité est bien installée. Les sites qui s’appuient sur les mises à jour automatiques en arrière-plan doivent tout de même le confirmer manuellement.
• Couper l’accès web au répertoire de mise à niveau. Restreindre l’accès public à wp-content/upgrade réduit l’exposition tant que le correctif n’est pas appliqué. Un pare-feu reste une couche supplémentaire, jamais un remplaçant du correctif.
• Auditer les journaux. Recherchez les requêtes inhabituelles vers des fichiers PHP sous wp-content/upgrade. C’est le signe le plus fiable d’une tentative visant la fenêtre de mise à niveau.
• Vérifier les comptes et les fichiers. Passez en revue les comptes administrateur, les extensions et les modifications de fichiers récentes. Un compte inconnu ou une extension ajoutée sans raison est un indice à creuser.

Deux commandes suffisent pour un premier tri côté serveur :

# Requêtes qui ont visé le répertoire de mise à niveau
grep -E "wp-content/upgrade" /var/log/nginx/access.log | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head

# Fichiers modifiés récemment sous le répertoire de mise à niveau
find wp-content/upgrade -type f -mmin -1440 -ls

Ce sont des indices, pas des preuves : une requête bloquée n’est pas une compromission, mais un fichier résiduel inattendu mérite une investigation.

WordPress annonce des backports pour les branches plus anciennes encore éligibles, tout en rappelant que seule la dernière version reste activement supportée. En clair : si vous êtes encore sur une branche 4.x ou 5.x, le vrai correctif s’appelle une migration, pas un patch de sécurité.

Verdict

La faille est une course de vitesse — difficile à exploiter à la main, mais déjà automatisée à l’échelle : 18 500 requêtes en 21 heures suffisent à montrer que l’attaquant n’attendra pas votre fenêtre de maintenance. Le risque réel n’est pas la sophistication de la technique, c’est le volume de tentatives et la prévisibilité du chemin de staging.

Si vous hébergez WordPress, appliquez 7.1.4 sans attendre la fin de semaine : c’est un correctif de sécurité trivial à déployer, et l’échéance CISA du 6 novembre indique déjà l’urgence attendue des équipes. Si vous êtes sur une version ancienne, le correctif ne suffit pas — planifiez la montée de version, car les branches historiques n’ont plus de support actif. Dans les deux cas, traitez chaque requête bloquée vers wp-content/upgrade comme un signal à investiguer, pas comme une preuve que tout va bien.

Références

• CISA — Known Exploited Vulnerabilities Catalog, CVE-2026-119977 (3 novembre 2026)
• Cyber Security News — CISA Warns of WordPress Core Vulnerability Exploited in Attacks (4 novembre 2026)
• The Hacker News — CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades (4 novembre 2026)
• WordPress — Version 7.1.4 Security and Maintenance Release (28 octobre 2026)
• CVE — CVE-2026-119977 (Wordfence, CNA)