WordPress : une faille du cœur exploitée pendant la mise à jour, passez en 7.1.4

1. Ce que disent les sources

WordPress a publié la version 7.1.4 le 28 octobre. Son annonce décrit « une faiblesse du processus de mise à jour qui peut mener à une exécution de code à distance pendant la fenêtre de mise à jour », signalée par le chercheur Umut Bayram. La même version corrige plusieurs failles de type XSS stocké, et le message officiel recommande une mise à jour immédiate.

Le 3 novembre, CISA a ajouté CVE-2026-119977 à son catalogue des failles exploitées. Selon BleepingComputer, l'agence n'a pas précisé qui attaque ni combien de sites sont touchés. L'entreprise Wordfence indique de son côté avoir bloqué 13 095 attaques visant cette faille en 24 heures. Ce chiffre mesure des tentatives, pas des sites piratés.

2. Comment l'attaque se déroule

Le mécanisme est une course de vitesse, que les spécialistes appellent une condition de concurrence. Quatre temps suffisent à le comprendre.

Le risque est donc ponctuel, mais il se répète à chaque mise à jour complète du cœur. Les attaquants peuvent envoyer des requêtes en continu pour attraper la fenêtre, ce qui explique le volume d'attaques bloquées. WordPress est déjà une cible de choix : BleepingComputer rappelle qu'en juillet une autre chaîne de failles, nommée wp2shell, avait vu des exploits publics sortir un jour après le correctif, puis des sites non corrigés être compromis quelques jours plus tard.

3. Vérifier votre version

Dans le Tableau de bord, ouvrez la rubrique Mises à jour : WordPress y indique la version installée et propose la mise à jour. Si vous avez un accès au serveur, WP-CLI donne la réponse en une commande :

cd /var/www/html/wordpress
wp core version
wp core check-update

Si la version est inférieure à 7.1.4, ne lancez pas tout de suite la mise à jour. Faites d'abord une sauvegarde complète (fichiers et base de données), puis bloquez le dossier temporaire en suivant la partie 4. Ce n'est qu'ensuite que vous mettez à jour, depuis le Tableau de bord.

Un point contre-intuitif : la commande wp core update de WP-CLI ne vous protège pas, d'après le chercheur, car elle utilise le même mécanisme et le même dossier. L'autre voie sûre est une mise à jour manuelle : on décompresse la nouvelle version dans un dossier que le serveur web ne sert pas, on copie les fichiers du cœur sans toucher à wp-config.php ni à wp-content, puis on lance la mise à jour de la base de données. Le meilleur moment est une période calme, car c'est pendant la mise à jour que le site est le plus exposé. Si vous êtes sur une ancienne branche, WordPress annonce des correctifs reportés jusqu'à la 4.7, livrés au fur et à mesure, mais précise que seule la version la plus récente est réellement maintenue. Passer à la 7.1.4 reste la solution la plus sûre. Les sites qui reçoivent les mises à jour automatiques doivent quand même contrôler le résultat.

4. Bloquer le dossier avant de mettre à jour

Pourquoi cette précaution ? Le correctif donne au dossier temporaire un nom aléatoire. Mais la mise à jour qui installe ce correctif décompresse encore ses fichiers avec l'ancien code du site, qui, selon The Hacker News, nomme le dossier d'après le fichier téléchargé : le nom reste prévisible une dernière fois. Interdire l'accès web au dossier supprime la fenêtre d'attaque. WordPress écrit dans ce dossier directement sur le disque, donc le blocage ne gêne pas les mises à jour, d'après le chercheur.

Sur nginx, ajoutez la règle dans le bloc server du site, testez la configuration, rechargez, puis vérifiez que le dossier répond bien par une erreur 403 :

# dans le bloc server du site WordPress
location ^~ /wp-content/upgrade/ {
    deny all;
}

sudo nginx -t && sudo systemctl reload nginx
curl -I https://votre-site.fr/wp-content/upgrade/

Sur Apache, ajoutez « Require all denied » dans un bloc Directory pour ce dossier. Si vous ne pouvez modifier que le fichier .htaccess, ajoutez RedirectMatch 403 ^/wp-content/upgrade/ à la racine de WordPress, au-dessus des règles de réécriture. Ne créez pas de fichier .htaccess dans le dossier wp-content/upgrade lui-même : l'ancien code vide ce dossier avant de décompresser la mise à jour, et le fichier disparaîtrait.

Une fois la 7.1.4 (ou le correctif de votre branche) installée, les mises à jour suivantes utilisent un nom aléatoire. Gardez le blocage : il ne coûte rien. Un pare-feu applicatif reste une couche de plus, jamais un correctif. Les sites en WordPress 4.6 ou plus ancien ne reçoivent plus de correctifs de sécurité : ils doivent passer sur une version maintenue.

5. Chercher des traces

Les journaux du serveur gardent la trace des requêtes visant les dossiers de mise à jour. Cherchez-y des accès à wp-content/upgrade, surtout vers des fichiers PHP :

sudo zgrep -h "wp-content/upgrade" /var/log/nginx/access.log* | head -n 50
sudo ls -la /var/www/html/wordpress/wp-content/upgrade

Une requête bloquée ou en erreur ne prouve pas une intrusion. Ce qui inquiète : un dossier temporaire qui traîne après une mise à jour, des comptes administrateurs inconnus, des extensions que vous n'avez pas installées, des fichiers PHP récents dans wp-content. Voici deux contrôles rapides :

wp user list --role=administrator
wp plugin list

Notre guide de détection détaille la méthode, et l'article Faut-il couper son site en cas de faille critique ? aide à décider d'isoler le site en cas de doute sérieux.

6. Conformité

Appliquer les correctifs de sécurité relève de l'article 32 du RGPD, dès lors que votre site traite des données personnelles : formulaires de contact, comptes clients, commandes. Notez la date de la mise à jour et la version installée. Si une intrusion est avérée et touche des données personnelles, la notification à la CNIL se fait sous 72 heures. Les entités soumises à NIS2 ont en plus une alerte précoce à émettre sous 24 heures pour un incident significatif.

7. Ce que 2LKATIME recommande

Mettez en place une routine : une veille sur les versions de WordPress et de ses extensions, un délai maximal entre la sortie d'un correctif de sécurité et son installation, et une sauvegarde testée avant chaque mise à jour du cœur. Nos audits cybersécurité couvrent la configuration du serveur, le durcissement de WordPress et la détection des traces d'intrusion.

Les entreprises de Paris, de Lyon ou de Bordeaux trouveront les formules sur nos pages tarifs. L'accompagnement se fait aussi à distance partout en France.

FAQ - Faille WordPress CVE-2026-119977