Le 28 octobre 2026, WordPress a publié la version 7.1.4, une mise à jour de sécurité. Parmi les failles corrigées, une seule mérite qu'un dirigeant s'y arrête : elle n'existe que pendant la mise à jour du site elle-même. Le 3 novembre, l'agence américaine de cybersécurité (CISA) l'a inscrite à son catalogue des failles exploitées, sous le numéro CVE-2026-119977.
En septembre, la faille corrigée par la version 7.1.2 posait une question simple : votre site se met-il bien à jour ? Nous l'avions traitée dans notre article sur la faille WordPress 7.1.2. Celle-ci pose une question moins habituelle : comment mettre à jour sans s'exposer pendant les quelques secondes où le site change de version ? Et comment savoir, après coup, si quelqu'un en a profité ?
Ce qui se passe pendant une mise à jour
Quand WordPress installe une nouvelle version complète de son cœur, il télécharge l'archive, puis la décompresse dans un dossier de travail, wp-content/upgrade, avant de copier les fichiers à leur place. Selon l'avis de sécurité publié par l'équipe WordPress, ce dossier portait jusqu'ici un nom prévisible et il est servi par le serveur web, donc joignable depuis Internet.
Pensez à un déménagement : pendant quelques minutes, les cartons sont sur le trottoir, porte ouverte. Parmi les fichiers décompressés figure l'assistant d'installation de WordPress. Un attaquant qui connaît l'emplacement et arrive au bon moment peut l'appeler et faire exécuter son propre code sur le serveur. Il n'a besoin d'aucun compte ni d'aucun clic de votre part. En revanche, il doit tomber pile dans la fenêtre : quelques secondes dans les tests de Wordfence, l'éditeur de sécurité qui a attribué le numéro de la faille.
Deux précisions rassurantes. Seule la mise à jour du cœur avec le paquet complet est concernée, pas celles des extensions ni des thèmes. Et la difficulté est réelle : l'équipe WordPress classe la faille en gravité faible, Wordfence lui donne 8,1 sur 10, avec une complexité d'attaque jugée élevée. Le classement de la CISA change toutefois la donne : la faille est exploitée, et Wordfence dit avoir observé des requêtes automatisées vers ces dossiers de travail dès les heures qui ont suivi le correctif.
Quelles versions sont concernées
Toutes les versions de 4.7 à 7.1.3. L'équipe WordPress a reporté le correctif sur chaque branche encore éligible, ce qui permet de rester sur sa branche si une montée de version majeure n'est pas possible tout de suite. Extrait du tableau officiel :
| Votre branche | Version corrigée |
|---|
| 7.1 | 7.1.4 |
| 7.0 | 7.0.8 |
| 6.9 | 6.9.11 |
| 6.8 | 6.8.12 |
| 6.7 | 6.7.11 |
| 6.6 | 6.6.11 |
| 6.5 | 6.5.14 |
| 6.4 | 6.4.14 |
| 6.0 à 6.3 | 6.0.18, 6.1.16, 6.2.15, 6.3.14 |
| 5.0 à 5.9 | de 5.0.31 à 5.9.20 (voir l'avis WordPress) |
| 4.7 à 4.9 | 4.7.39, 4.8.34, 4.9.35 |
| 4.6 et avant | aucun correctif |
La dernière ligne est celle qui inquiète. Un site resté en 4.6 ou avant ne recevra rien. Pour lui, la seule réponse est une migration vers une version maintenue, et la question devient celle de l'état général de sa sécurité, extensions comprises.
Le paradoxe : le correctif s'installe avec l'ancien code
C'est le point que beaucoup de sites vont rater. Pour passer en 7.1.4, votre WordPress utilise son programme de mise à jour actuel, celui qui contient la faille. La fenêtre peut donc s'ouvrir une dernière fois pendant l'installation du correctif. Plusieurs analyses de sécurité le soulignent depuis fin octobre.
La parade est simple et ne casse rien : interdire l'accès web au dossier wp-content/upgrade avant de lancer la mise à jour. WordPress continue d'y écrire ses fichiers, mais personne ne peut plus les appeler depuis Internet. La règle se pose dans la configuration du serveur, ou dans le fichier .htaccess à la racine du site, jamais dans le dossier lui-même. Deux exemples à transmettre à votre prestataire :
# Apache, fichier .htaccess à la racine du site
RedirectMatch 403 ^/wp-content/upgrade/
# Nginx, bloc server du site
location ^~ /wp-content/upgrade/ { deny all; }
Ensuite, l'ordre des opérations :
- une sauvegarde complète (fichiers et base de données), testée, avant toute intervention ;
- le blocage du dossier ci-dessus, vérifié en tapant l'adresse
votresite.re/wp-content/upgrade/ dans un navigateur : la réponse doit être un refus d'accès ;
- la mise à jour, de préférence à une heure creuse ;
- la vérification de la version réellement installée, dans le tableau de bord, rubrique Mises à jour, ou dans Outils, puis Santé du site.
Un détail compte si vous protégez votre site avec une extension de sécurité : la requête malveillante vise directement un fichier PHP et ne passe pas par WordPress. Une extension classique ne la voit donc pas toujours. Le blocage au niveau du serveur, lui, fonctionne dans tous les cas.
Vérifier après coup : le correctif ne répare pas le passé
Mettre à jour ferme la porte. Cela ne dit rien de ce qui a pu entrer avant. Si votre site a fait une mise à jour du cœur sans être protégé, en particulier depuis le 28 octobre, quatre vérifications s'imposent, à confier à votre prestataire ou à votre hébergeur :
- dans les journaux d'accès du serveur, des requêtes vers des fichiers sous
wp-content/upgrade, notamment setup-config.php, autour des dates de mise à jour ;
- des comptes administrateurs que personne ne reconnaît ;
- des extensions installées sans que vous l'ayez demandé ;
- des fichiers PHP récents que ni vous ni votre prestataire n'avez déposés.
Ne comptez pas sur une liste d'adresses suspectes pour trancher. Les robots qui balaient Internet à la recherche de ce dossier sont nombreux : retrouver l'un d'eux dans vos journaux prouve que le site a été visé, pas qu'il a été touché. La vérification repose donc sur ces signes. Bonne nouvelle relative : au 10 novembre 2026, ni la CISA, ni le CERT-FR, ni les éditeurs de sécurité n'ont décrit publiquement de prise de contrôle réussie. Les tentatives, elles, sont documentées.
Ce que nous en retenons
WordPress n'est pas le problème. Son équipe a corrigé la faille et l'a reportée sur vingt-cinq branches, jusqu'à des versions de 2016. Le problème, comme pour la faille PHP2Shell d'octobre, c'est l'écart entre « la mise à jour est disponible » et « quelqu'un s'en occupe correctement ». Ici, mettre à jour mécaniquement ne suffit même pas : il faut savoir comment le faire.
Trois failles sérieuses en six semaines, sur WordPress puis sur PHP : le rythme s'accélère, et les robots qui guettent les correctifs aussi. C'est un argument pour un contrat de maintenance clair, quel que soit l'outil de votre site. Nous en avions détaillé les responsabilités dans notre article sur la mise à jour d'un site avant le pic de ventes.
Quatre questions à poser à votre prestataire
- Quelle version de WordPress tourne sur mon site aujourd'hui, et est-ce bien la version corrigée de sa branche ?
- L'accès web au dossier
wp-content/upgrade a-t-il été bloqué avant la mise à jour ?
- Avez-vous regardé les journaux d'accès autour des dates de mise à jour du cœur depuis fin octobre ?
- Qui est prévenu, et sous quel délai, la prochaine fois qu'une faille de ce type sort ?
Si vous n'obtenez pas de réponse écrite à ces quatre questions, c'est une information en soi. Nous pouvons faire le point avec vous : ce que couvre un diagnostic de sécurité, puis un audit gratuit de votre site. Pour un projet de refonte ou de reprise, consultez notre page agence web à La Réunion, nos sites vitrines sur mesure, ou écrivez-nous.
Sources : annonce WordPress 7.1.4 (28 octobre 2026) et avis de sécurité GHSA-4w3m-c66w-69mg de l'équipe WordPress (29 octobre) ; avis CERT-FR CERTFR-2026-AVI-1420 (29 octobre, mis à jour le 6 novembre) ; bulletin AV26-1117 du Centre canadien pour la cybersécurité (3 novembre), qui relaie l'inscription au catalogue de la CISA ; analyses de Wordfence et Patchstack citées par Rescana et SOC Prime. Faits arrêtés au 10 novembre 2026.
