Version de sécurité WordPress 7.1.4 : ce que les agences doivent faire aujourd’hui

Mise à jour, 5 novembre 2026 : Wordfence compte désormais plus de 240 000 tentatives bloquées contre cette faille depuis le 28 octobre, avec un pic de plus de 74 000 le 30 octobre. La CISA a ajouté CVE-2026-119977 à son catalogue Known Exploited Vulnerabilities le 2 novembre. Wordfence juge toujours une attaque réussie difficile en pratique, car elle ne fonctionne que pendant les secondes où une mise à jour tourne. Leur conseil est le même que le nôtre : mettez à jour vers 7.1.4 ou le correctif de votre branche maintenant, et bloquez les fichiers PHP dans wp-content/upgrade/ au niveau du serveur web avant la mise à jour. Les utilisateurs gratuits de Wordfence reçoivent la règle de pare-feu le 27 novembre. Source : Wordfence, 5 novembre 2026.

Mise à jour, 31 octobre 2026 : les attaques augmentent. Wordfence signale maintenant près de 59 000 tentatives bloquées en 24 heures contre les fichiers d’installation temporaires dans wp-content/upgrade/ (contre 18 500 dans les 21 premières heures). Toujours aucune intrusion confirmée. Si un site client n’est pas encore en 7.1.4 ou sur le correctif de sa branche, mettez-le à jour aujourd’hui et fermez le dossier upgrade au niveau du serveur ; n’attendez pas lundi.

WordPress 7.1.4 est sorti le 28 octobre 2026 comme version de sécurité. Elle corrige 22 vulnérabilités réparties sur 17 avis, et les mêmes corrections ont été reportées sur chaque branche prise en charge jusqu’à la 4.7.39. L’une d’elles est inhabituelle : une faille dans le processus de mise à jour du cœur lui-même, sans connexion nécessaire. Elle est difficile à exploiter, mais les attaquants ont commencé à la chercher en moins d’un jour, et c’est le seul problème de cette version qu’un pare-feu sous forme d’extension ne peut pas arrêter. Voici ce que cela signifie pour les sites clients que vous maintenez, et que faire aujourd’hui.

Ce qui est corrigé

• Exécution de code sans connexion pendant une mise à jour. Avant la 7.1.4, le dossier dans lequel WordPress décompresse les mises à jour, à l’intérieur de wp-content/upgrade/, avait un nom prévisible, et le nettoyage supprimait le index.php qui bloque l’affichage du contenu du dossier. Un attaquant qui tombe sur les quelques secondes où une mise à jour tourne, sur un site où ce dossier est accessible par le web, pouvait exécuter du code. Patchstack juge la complexité de l’attaque élevée et ne considère pas l’exploitation comme réaliste. Comme la copie décompressée ne charge pas les extensions de votre site, une extension pare-feu au niveau PHP ne peut pas bloquer cette requête.
• XSS stockée à partir des comptes Contributeur et plus, surtout dans l’Interactivity API (7 des 17 avis) et dans plusieurs blocs du cœur.
• Customizer : des jeux de modifications non publiés pouvaient être vus par des visiteurs non connectés.

Qui est concerné

Tout site en version inférieure à 7.1.4 ou au correctif correspondant (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 et ainsi de suite, jusqu’à 4.7.39). Les sites en 4.6 ou plus ancien ne reçoivent aucune correction. Les problèmes XSS comptent surtout sur les sites où des clients, rédacteurs ou auteurs invités ont des comptes Contributeur ou plus.

Vérifier un site en deux minutes

1. Version : dans wp-admin, allez dans Tableau de bord → Mises à jour, ou lancez wp core version. Tout ce qui est en dessous de 7.1.4 (ou du correctif de votre branche) a besoin de la mise à jour.
2. Dossier upgrade : ouvrez https://example.com/wp-content/upgrade/ dans une fenêtre privée. Un 403 ou un 404, c’est ce que vous voulez. Une liste de fichiers ou une page 200 vide signifie que le dossier est accessible par le web.
3. Comptes : dans Utilisateurs, filtrez sur Contributeur, Auteur et Éditeur. Supprimez ceux que personne n’utilise.

Que faire maintenant

1. Mettez à jour le cœur vers 7.1.4 ou le correctif de votre branche. Les petites versions de sécurité s’installent normalement seules ; vérifiez que c’est bien le cas, car des hébergeurs et certaines extensions désactivent les mises à jour automatiques du cœur. Assurez-vous d’abord d’avoir une sauvegarde récente, et vérifiez ensuite la page d’accueil, un formulaire et le paiement.
2. Bloquez l’accès web au dossier upgrade au niveau du serveur web, pas dans une extension. Sous Apache, un fichier .htaccess dans wp-content/upgrade/ avec Require all denied. Sous nginx, location ^~ /wp-content/upgrade/ { deny all; }. WordPress écrit toujours dans le dossier via PHP, donc les mises à jour continuent de fonctionner. Sur un hébergement infogéré où vous ne pouvez pas modifier le serveur, demandez-le à votre hébergeur.
3. Sites en 4.6 ou plus ancien : planifiez dès maintenant le passage à une version prise en charge. Il n’y aura pas de correction pour eux.

Les attaquants cherchent cette faille, mais aucune intrusion réussie n’a été confirmée : un site à jour avec un dossier upgrade fermé n’a besoin ni de restauration ni de nouvelles clés à cause de cette seule version. Si vous voyez des fichiers inconnus dans wp-content/upgrade/ ou de nouveaux comptes administrateur, traitez-le comme une compromission : restaurez depuis une sauvegarde d’avant l’apparition de ces fichiers, puis changez mots de passe et clés de salage. Notre routine pour un jour de vulnérabilité donne toutes les étapes.

Comment Verploy aide

Chaque mise à jour est vérifiée. Les plus risquées sont d’abord testées sur une copie. Le cœur de WordPress compte toujours comme risqué : il est testé sur une copie privée du site avant que le site en ligne ne change, et si un contrôle échoue après la mise en ligne, le site revient automatiquement en arrière. Des sauvegardes nocturnes chiffrées dans l’UE vous donnent un point propre où revenir, et les vulnérabilités connues apparaissent par site avec un lien vers la source.

Source : Patchstack, « WordPress 7.1.4 Security Release », 28 octobre 2026, patchstack.com. Avertissement d’exploitation de Wordfence, 29 octobre 2026, rapporté par SecurityOnline; chiffre sur 24 heures rapporté par CyberPress, 31 octobre 2026. Vérifié le 31 octobre 2026.