WordPress a publié la version 7.1.4 le 28 octobre 2026, avec des correctifs pour 22 problèmes de sécurité. L'un d'eux sort de l'ordinaire : il ne se trouve ni dans une extension ni dans un thème, mais dans le programme de mise à jour de WordPress lui-même, et il peut être exploité sans compte sur votre site.
Les attaquants ont réagi vite. Wordfence a publié une règle de pare-feu le soir même de la sortie de la version et a constaté la première tentative d'attaque neuf minutes plus tard. Dans les jours qui ont suivi, il bloquait des dizaines de milliers de tentatives toutes les 24 heures. Ce guide explique en quoi consiste la faille, quelles versions la corrigent et comment mettre à jour sans laisser la porte ouverte pendant l'opération.
À retenir
- WordPress 7.1.4 (28 octobre 2026) corrige 22 problèmes de sécurité. Tous les sites devraient passer à cette version, ou à la version corrigée de leur branche.
- La faille principale, CVE-2026-119977, permet à un attaquant sans compte d'exécuter du code pendant une mise à jour du cœur. Wordfence lui attribue un score de 8.1 (élevé).
- Les attaquants ont commencé leurs tentatives moins de neuf minutes après la première règle de pare-feu, avec des dizaines de milliers d'essais par jour depuis.
- Bloquez l'accès web à wp-content/upgrade/ avant la mise à jour, puis mettez à jour et recherchez d'éventuels signes d'intrusion.
- WordPress 4.6 et les versions antérieures ne reçoivent aucun correctif. Ces sites doivent être entièrement mis à niveau.
En bref Ajoutez la règle d'une ligne ci-dessous pour bloquer l'accès web à wp-content/upgrade/, puis passez à la version 7.1.4 (ou à la version corrigée de votre branche), et enfin vérifiez l'absence de comptes administrateur inconnus. Si votre site tourne sous WordPress 4.6 ou une version antérieure, il n'existe aucun correctif : une mise à niveau complète est nécessaire.
En quoi consiste la faille du programme de mise à jour
La faille est référencée sous l'identifiant CVE-2026-119977. Wordfence lui attribue un score de 8.1 sur 10 (élevé). WordPress l'évalue plus bas, car elle est difficile à exploiter, mais « difficile » ne veut pas dire « sans danger » quand des robots peuvent essayer des milliers de fois par jour.
Lorsque WordPress installe une mise à jour complète du cœur, il décompresse d'abord les nouveaux fichiers dans un dossier situé sous wp-content/upgrade/. Sur les versions concernées, ce dossier portait un nom prévisible et, sur de nombreux serveurs, était accessible depuis le web. Pendant quelques secondes, n'importe qui pouvait ouvrir la copie de l'installateur WordPress qu'il contenait et la faire pointer vers une base de données contrôlée par l'attaquant, ce qui lui permettait d'exécuter du code sur votre serveur.
Quatre conditions doivent être réunies : une mise à jour par paquet complet doit être en cours, le dossier doit être accessible depuis le web, l'attaquant doit en trouver le chemin et il doit gagner la course avant que WordPress ne fasse le ménage. Les robots se chargent des trois dernières en interrogeant les sites encore et encore, d'où le nombre si élevé de tentatives.
La version 7.1.4 corrige le problème en ajoutant 16 caractères aléatoires au nom du dossier temporaire, en conservant un fichier de protection index.php dans le dossier upgrade et en refusant de copier la configuration depuis la copie temporaire. Les 21 autres correctifs concernent des failles de cross-site scripting, des problèmes liés à l'Interactivity API, des fuites d'informations vers des visiteurs non connectés, des contrôles de permissions et une mise à jour des certificats racine fournis.
Quelles versions sont corrigées
Le correctif a été rétroporté sur toutes les branches qui reçoivent encore des mises à jour de sécurité. Passez au minimum à :
- 7.1.4 sur la branche 7.1, ou 7.0.8 sur la 7.0 ;
- 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14 ou 6.4.14 sur les branches 6.x ;
- la version corrigée correspondante sur les branches 6.x plus anciennes, 5.x et 4.7–4.9, jusqu'à 4.7.39.
WordPress 4.6 et les versions antérieures ne reçoivent aucun correctif. Par ailleurs, les rétroportages ne couvrent que les problèmes de sécurité : la meilleure cible pour tout site reste donc la dernière version, 7.1.4.
Étape 1 : bloquer d'abord le dossier upgrade
Le moment vulnérable, c'est la mise à jour elle-même : refermez donc la brèche avant de mettre à jour. Ajoutez cette règle au fichier .htaccess situé dans le dossier racine de votre site (dans cPanel, Gestionnaire de fichiers › public_html, en affichant les fichiers cachés), au-dessus du bloc # BEGIN WordPress :
# Block web access to WordPress update staging files (CVE-2026-119977)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>Placez-la dans le fichier .htaccess racine, et non dans le dossier upgrade : WordPress vide ce dossier avant chaque mise à jour. La règle n'a aucun effet sur les mises à jour, car WordPress lit ces fichiers sur le serveur, et non via le web. Elle fonctionne sur les serveurs LiteSpeed de WebGee, ainsi que sur tout serveur compatible Apache.
Étape 2 : mettre à jour
Commencez par faire une sauvegarde récente. Sur l'hébergement cPanel de WebGee, JetBackup vous permet d'en créer une à la demande en quelques clics. Lancez ensuite la mise à jour depuis Tableau de bord › Mises à jour › Mettre à jour vers la version 7.1.4, ou en SSH :
# Check the current version
wp core version
# Update core, then the database if asked
wp core update
wp core update-db
# Confirm
wp core versionLes sites dont les mises à jour automatiques en arrière-plan sont activées devraient déjà être en 7.1.4, mais vérifiez quand même. Les mises à jour automatiques échouent discrètement plus souvent qu'on ne le pense, par exemple après une modification des permissions de fichiers ou lorsque le disque est plein.
Étape 3 : vérifier que personne ne s'est introduit
Aucune compromission confirmée n'avait été signalée au moment de la rédaction, et aucune liste d'adresses IP ou de fichiers malveillants n'a été publiée. Recherchez plutôt des comportements suspects :
Après la mise à jour, vérifiez
- Les comptes administrateur que vous ne reconnaissez pas (Comptes › Tous les comptes, filtrés par Administrateur)
- Les extensions que vous n'avez pas installées, y compris celles qui portent le nom de votre propre domaine
- Les fichiers PHP inattendus sous wp-content/upgrade/ ou wp-content/uploads/
- Les requêtes vers setup-config.php ou d'autres fichiers PHP sous wp-content/upgrade/ dans vos journaux d'accès
- Les modifications de wp-config.php ou de .htaccess survenues au moment des mises à jour du cœur
Sur l'hébergement cPanel de WebGee, vous pouvez également lancer une analyse antimalware depuis cPanel, et le rapport CMS Threats de cPGuard affiche chaque installation WordPress du compte avec sa version du cœur : une copie oubliée encore sur une ancienne version saute ainsi aux yeux. Si vous trouvez quelque chose, suivez notre procédure de nettoyage des malwares ou ouvrez un ticket.
N'oubliez pas les copies Les anciennes installations dans des dossiers comme /old, /test ou /staging subissent les mêmes attaques que votre site principal, et ce sont généralement celles que personne ne met à jour. Mettez-les à jour ou supprimez-les.
Quatre versions de sécurité depuis septembre
La version 7.1.4 succède aux versions 7.1.1, 7.1.2 et 7.1.3 en moins de six semaines, et WordPress 7.2 arrive le 8 décembre. Suivre ce rythme seul est un véritable travail. Avec l'hébergement WordPress de WebGee, vous bénéficiez de sauvegardes, d'une analyse de sécurité au niveau du serveur, d'un environnement de préproduction à partir de l'offre Turbo et d'ingénieurs disponibles 24 h/24 et 7 j/7 sur le chat en direct, qui gèrent les mises à jour WordPress au quotidien.
Questions fréquentes
Quelles versions corrigent la CVE-2026-119977 ?
WordPress 7.1.4, ainsi que des versions corrigées pour les branches plus anciennes, dont 7.0.8, 6.9.11, 6.8.12 et jusqu'à 4.7.39. WordPress 4.6 et les versions antérieures ne reçoivent aucun correctif.
Mon site se met à jour automatiquement. Dois-je faire quelque chose ?
Vérifiez que la mise à jour a bien eu lieu : Tableau de bord › Mises à jour ou wp core version doit afficher 7.1.4 ou la version corrigée de votre branche. Les mises à jour automatiques peuvent échouer sans prévenir, par exemple en cas de problème de permissions de fichiers.
La faille peut-elle être exploitée en dehors d'une mise à jour ?
Non. La faille n'existe que pendant les quelques secondes où une mise à jour complète du cœur décompresse les fichiers dans wp-content/upgrade/. C'est pourquoi bloquer ce dossier avant la mise à jour suffit à la neutraliser.
Des sites ont-ils été piratés par ce biais ?
Au moment de la rédaction, aucune compromission confirmée n'avait été signalée, seulement un grand nombre de tentatives bloquées. La situation peut évoluer rapidement, alors n'attendez pas.
Bloquer wp-content/upgrade/ empêchera-t-il les mises à jour ?
Non. WordPress lit et écrit dans ce dossier directement sur le serveur ; la règle empêche uniquement les navigateurs et les robots de demander les fichiers qu'il contient.
