En bref
La faille CVE-2026-119977, corrigée le 28 octobre 2026 dans WordPress 7.1.4, est déjà visée par des attaques automatisées : Wordfence a compté plus de 18 500 requêtes en 21 heures vers les fichiers d’installation copiés dans wp-content/upgrade/ pendant une mise à jour. Notée 8.1 sur 10 par Wordfence, elle touche WordPress 4.7 à 7.1.3. Mettez à jour, bloquez l’accès web à wp-content/upgrade/ au niveau du serveur, puis contrôlez vos journaux, vos administrateurs et vos fichiers PHP.
Nous avons présenté la semaine dernière WordPress 7.1.4 et ses 22 failles corrigées. Depuis, la faille du processus de mise à jour, la seule de la liste qui ne demande aucun compte sur le site, est ciblée par des robots. Aucune compromission n’avait été confirmée publiquement au 31 octobre, mais la mise à jour seule ne suffit pas. Si votre site montre déjà des signes d’intrusion (administrateur inconnu, fichiers PHP inexpliqués), passez à la dernière partie ou confiez le diagnostic à notre service de nettoyage de site WordPress piraté.
Que se passe-t-il exactement avec la faille CVE-2026-119977 ?
Pendant une mise à jour du cœur, une copie temporaire de WordPress peut rester exposée sur le web quelques secondes, et un attaquant qui la joint au bon moment peut faire exécuter du code sur le serveur. WordPress décompresse en effet le nouveau paquet dans un sous-dossier de wp-content/upgrade/ dont le nom était prévisible avant 7.1.4, et ce dossier est accessible depuis un navigateur sur beaucoup de serveurs. Cette copie contient l’assistant d’installation (wp-admin/setup-config.php), qui fonctionne sans la configuration du vrai site.
C’est une « race condition », une course contre la montre : l’attaquant doit frapper pendant la fenêtre très courte où les fichiers existent. WordPress la juge donc de sévérité faible, alors que Wordfence lui donne un score CVSS (l’échelle de gravité des failles, de 0 à 10) de 8.1. Le correctif ajoute 16 caractères aléatoires au nom du dossier, conserve son index.php et exclut wp-config.php de la copie. Il existe pour chaque branche (7.0.8, 6.9.11, 6.8.12… jusqu’à 4.7.39) ; les versions 4.6 et antérieures ne sont plus corrigées.
Pourquoi faut-il agir même si votre site est déjà en 7.1.4 ?
Parce que la mise à jour vers 7.1.4 s’exécute encore avec l’ancien code : la fenêtre d’exposition s’est ouverte au moment même où votre site s’est mis à jour, souvent automatiquement dès le 28 octobre, alors que les robots interrogeaient déjà les sites en boucle. Et un pare-feu installé comme extension WordPress ne voit pas passer l’attaque, car la copie temporaire charge WordPress sans vos extensions. Seul un blocage au niveau du serveur web (Apache, Nginx) ou d’un pare-feu placé devant le site ferme la porte.
Votre site est-il concerné ?
Votre site est concerné s’il tournait sous une version comprise entre 4.7 et 7.1.3 et si le dossier wp-content/upgrade/ répond depuis l’extérieur. Pour la version, regardez le pied de page de l’administration, le menu Tableau de bord, puis Mises à jour, ou lancez cette commande WP-CLI (l’outil en ligne de commande de WordPress, disponible chez la plupart des hébergeurs en SSH) :
wp core versionPour savoir si le dossier est exposé, testez son adresse depuis votre ordinateur. Remplacez votre-site.fr par votre domaine :
curl -s -o /dev/null -w "%{http_code}\n" https://votre-site.fr/wp-content/upgrade/- 403 : l’accès est refusé, c’est le résultat attendu.
- 200 : le dossier répond. S’il affiche une liste de fichiers dans un navigateur, le listage est en plus activé : bloquez-le tout de suite.
- 404 : le dossier n’existe pas encore, ce qui ne protège pas la prochaine mise à jour.
Entre deux mises à jour, ce dossier ne doit contenir qu’un index.php. Si vous y voyez d’autres fichiers PHP, notez-les sans les supprimer et lisez la dernière partie.
Comment bloquer l’accès à wp-content/upgrade/ ?
Il faut refuser toute requête web vers ce dossier dans la configuration du serveur, puis mettre à jour. Sauvegardez fichiers et base de données avant. Ce blocage ne gêne pas les mises à jour, qui passent par le système de fichiers et non par le navigateur.
1. Sur un hébergement Apache ou LiteSpeed (fichier .htaccess)
Ajoutez ce bloc tout en haut du .htaccess situé à la racine du site, avant la ligne # BEGIN WordPress. Jamais dans le dossier upgrade lui-même, dont le contenu est effacé à chaque mise à jour.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>
Options -IndexesLa règle renvoie une erreur 403 sur tout le dossier et Options -Indexes coupe le listage des dossiers. Si le site passe en erreur 500, l’hébergeur interdit la directive Options : retirez cette ligne.
2. Sur un serveur Nginx
Ajoutez ce bloc dans le bloc server du site, puis testez et rechargez. Le préfixe ^~ empêche la règle qui transmet les fichiers .php à PHP de passer avant le blocage.
location ^~ /wp-content/upgrade/ {
deny all;
}sudo nginx -t && sudo systemctl reload nginxSans accès à cette configuration, demandez la règle au support de l’hébergeur en citant wp-content/upgrade/ et la CVE-2026-119977.
3. Mettre à jour et contrôler
Mettez à jour, vérifiez la version et l’intégrité des fichiers du cœur, puis refaites le test curl : il doit renvoyer 403.
wp core update --minor
wp core version
wp core verify-checksumsLa règle de pare-feu dédiée de Wordfence n’arrivera que le 27 novembre 2026 pour la version gratuite. Si votre site ne s’est pas mis à jour tout seul, notre article sur WordPress 7.1.4 donne les causes et les commandes pour les trouver.
Comment savoir si votre site a déjà été touché ?
Il faut croiser trois sources : les journaux d’accès du serveur, la liste des administrateurs et les fichiers PHP récents. Dans les journaux d’accès (access.log, fournis par l’hébergeur), cherchez les requêtes vers le dossier upgrade qui n’ont pas été refusées :
grep "wp-content/upgrade/" access.log | grep -v '" 403 '
zgrep "wp-content/upgrade/" access.log*.gz | grep -v '" 403 'Des requêtes vers un setup-config.php situé sous wp-content/upgrade/ montrent que votre site a été visé ; une réponse 200 ou 302 au moment où il se mettait à jour doit vous alerter. Contrôlez ensuite les comptes et les extensions :
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list
wp plugin verify-checksums --allEnfin, aucun fichier PHP ne doit se trouver dans le dossier des médias, et chaque fichier modifié depuis le 28 octobre doit correspondre à une mise à jour connue :
find wp-content/uploads -name "*.php"
find . -name "*.php" -newermt "2026-10-28" -not -path "./wp-content/upgrade/*"
ls -la wp-content/mu-plugins/Nous n’aimons pas du tout
Supprimer un fichier suspect et passer à autre chose. Les portes dérobées actuelles se reconstruisent depuis plusieurs copies (fichiers, base de données, tâches planifiées) : un nettoyage partiel laisse souvent l’attaquant revenir.
Au moindre administrateur inconnu ou code inexpliqué, arrêtez-vous : changez les mots de passe des administrateurs et de l’hébergement, gardez une copie du site en l’état et faites intervenir un professionnel. Notre guide pour détecter les malwares sur un site WordPress détaille les autres traces à chercher, et notre scanner de sécurité WordPress offre un premier contrôle externe gratuit.
En conclusion :
La faille CVE-2026-119977 demande un timing précis, mais elle est attaquée en masse et un pare-feu installé comme extension ne l’arrête pas. Mettez à jour, bloquez wp-content/upgrade/ au niveau du serveur et gardez ce blocage. Si vos journaux ou vos comptes montrent une trace suspecte, notre équipe DépannageWP nettoie les sites WordPress piratés et ferme la faille, à distance, du lundi au vendredi, après un audit gratuit. Ce type d’intervention prend en général 3 à 6 heures (210 à 420 € TTC au tarif normal, voir notre tarification).
Sources : annonce WordPress 7.1.4, notes de version 7.1.4, fiche CVE-2026-119977, analyse Patchstack, avis CERT-FR CERTFR-2026-AVI-1420.
