WordPress 7.1.4 : la faille qui se cache dans la mise à jour elle-même

Que s'est-il passé avec WordPress 7.1.4 ?

Le 28 octobre 2026, l'équipe de WordPress a publié la version 7.1.4, une mise à jour de sécurité. Elle corrige plusieurs failles, dont une, référencée CVE-2026-119977, qui peut mener à l'exécution de code sur le serveur pendant la mise à jour du cœur de WordPress.

Le « cœur » de WordPress, c'est le programme de base du site, par opposition aux extensions et au thème. Quand vous cliquez sur « Mettre à jour », ou quand le site se met à jour tout seul, ce programme télécharge la nouvelle version, la dépose dans un dossier de travail, puis remplace les anciens fichiers. C'est dans ce dossier de travail que se situe le problème.

La note de version officielle recommande de mettre les sites à jour immédiatement et précise que les sites qui acceptent les mises à jour automatiques en arrière-plan se corrigeront seuls. Le CERT-FR, le centre d'alerte de l'État français, a publié le 29 octobre l'avis CERTFR-2026-AVI-1420 : il indique que des attaquants distants pourraient exécuter du code arbitraire, provoquer un déni de service ou accéder à des données, et que toutes les versions antérieures à la 7.1.4 sont concernées.

Le calendrier, d'après la note WordPress, l'analyse de Rescana et BleepingComputer :

Je précise tout de suite un point qui a son importance : à ma connaissance, aucune source fiable ne rapporte à ce jour un site réellement piraté par cette faille. Ce qui est documenté, ce sont des tentatives, nombreuses.

Comment une faille peut-elle se cacher dans la mise à jour de WordPress ?

Pendant une mise à jour complète du cœur, WordPress dépose les nouveaux fichiers, installateur compris, dans un dossier temporaire dont le nom est prévisible et qui peut être appelé depuis Internet. Un attaquant qui le demande au bon moment peut faire exécuter du code PHP par le serveur.

Les spécialistes parlent de « condition de course » (race condition) : deux événements se produisent presque en même temps, et c'est celui qui arrive le premier qui décide du résultat. Ici, d'un côté WordPress pose ses fichiers puis les nettoie, de l'autre un attaquant essaie d'atteindre ces fichiers avant qu'ils disparaissent. Le type de faille est classé « TOCTOU », pour time-of-check to time-of-use : on vérifie une chose à un instant, on s'en sert à un autre, et entre les deux la situation a changé.

D'après l'analyse de Rescana, qui reprend Wordfence et Patchstack, quatre conditions doivent être réunies pour qu'une attaque aboutisse :

1. Une mise à jour complète du cœur est en cours, c'est-à-dire avec le paquet entier, qui contient l'installateur.
2. Le serveur laisse l'accès web et PHP au dossier de travail situé sous wp-content/upgrade/.
3. Le chemin du dossier est prévisible ou peut être deviné.
4. Les fichiers restent là assez longtemps avant le nettoyage.

L'attaquant n'a besoin d'aucun compte ni d'aucun mot de passe. Il lui faut juste de la chance, ou plutôt de la patience : en envoyant sans arrêt des requêtes automatiques, il augmente ses chances de tomber sur la bonne seconde. Wordfence note que la fenêtre est étroite, mais que ces sondages répétés peuvent améliorer les probabilités.

Ce que corrige la 7.1.4, toujours selon Rescana : le dossier de travail reçoit un nom aléatoire de 16 caractères, un fichier de garde empêche d'en lister le contenu, et le fichier de configuration wp-config.php ne peut plus être déplacé hors du dossier de travail pendant l'opération.

Cette faille WordPress est-elle vraiment grave ?

Les avis divergent, et c'est normal : l'attaque est difficile à réussir, mais ses conséquences seraient lourdes, et les tentatives sont déjà massives. Je la traite comme une faille à corriger cette semaine, sans panique, mais sans attendre le prochain cycle de maintenance.

Voici les évaluations publiées, côte à côte :

Le CVSS est une note de 0 à 10 qui mesure la gravité théorique d'une faille. Un 8,1 comme ici est élevé, sans être au niveau des failles les plus critiques, qui permettent de prendre la main en une seule requête. La « complexité élevée » veut dire que l'attaquant doit réunir des conditions qu'il ne contrôle pas entièrement.

Côté exploitation, voici ce qui est publié. Selon Rescana, qui cite Wordfence, plus de 18 500 requêtes ciblant les chemins temporaires de l'installateur ont été enregistrées pendant les 21 premières heures. BleepingComputer rapporte, à partir d'une mise à jour de l'avis de Wordfence, 13 095 attaques bloquées sur 24 heures. Ces deux chiffres ne portent pas sur la même période et ne se comparent pas ; ce qu'ils montrent ensemble, c'est que le scan est massif et automatisé. Un autre média cite un chiffre beaucoup plus élevé, que je ne reprends pas, faute de l'avoir retrouvé dans l'analyse de Wordfence.

Mon avis, honnêtement : si votre site est mis à jour automatiquement, vous aurez probablement la correction sans rien faire. La vraie difficulté concerne les sites que personne ne surveille, ceux dont les mises à jour sont bloquées, ceux hébergés sur de vieilles versions. C'est là que ce type de faille fait des dégâts, et c'est là que les robots ne se découragent pas.

Comment savoir si mon site WordPress est concerné ?

Si votre site tourne sous une version de WordPress inférieure à la 7.1.4 (ou à la version corrigée de votre branche), il est concerné. Vous trouvez la version en bas à droite du tableau de bord, ou dans le menu Tableau de bord, puis Mises à jour.

La note de version de WordPress publie des correctifs pour de nombreuses branches. Voici celles qui nous intéressent le plus, d'après cette note et l'analyse de Rescana :

Le dernier cas mérite qu'on s'y arrête. Un site en 4.6 ou plus ancien date de 2016 ou avant. Il n'est pas seulement exposé à cette faille : il l'est à toutes celles qui ont été découvertes depuis. Dans ce cas, la bonne décision n'est pas de chercher un correctif qui n'existe pas, mais de migrer vers une version actuelle, ou de reconstruire le site.

Deux autres situations à vérifier, car ce sont elles qui posent problème en pratique :

• Les mises à jour automatiques sont désactivées, parfois par une extension de gestion, parfois à la demande d'un ancien prestataire qui voulait garder la main. Le site ne se corrigera jamais seul.
• Le site n'est plus suivi par personne : ancienne maquette, site d'un événement passé, site secondaire d'une filiale. Ces sites oubliés sont les premiers à tomber.

Si vous avez plusieurs sites, faites la liste de tous, y compris ceux dont vous n'êtes plus certain. C'est souvent à ce moment-là qu'on découvre qu'un ancien site tourne encore chez un hébergeur, avec une version vieille de plusieurs années.

Que faire aujourd'hui pour protéger un site WordPress ?

Bloquer l'accès web au dossier wp-content/upgrade/, puis mettre WordPress à jour vers la 7.1.4 ou la version corrigée de votre branche, puis vérifier la version effectivement installée. L'ordre compte, parce que la mise à jour est elle-même le moment à risque.

Voici la marche à suivre que je recommande, en reprenant les consignes de Patchstack, de Wordfence et de l'éditeur :

1. Faites une sauvegarde complète (fichiers et base de données), stockée ailleurs que sur le site. Sans elle, vous n'avez aucun plan B.
2. Bloquez l'accès web à wp-content/upgrade/ au niveau du serveur, et désactivez l'affichage du contenu des dossiers. Entre deux mises à jour, ce dossier ne contient normalement qu'un fichier index.php : le bloquer ne casse donc rien. Cette opération se fait dans la configuration du serveur (Nginx, Apache) ou via le panneau de votre hébergeur. Je ne donne pas ici de règle toute faite, car sa syntaxe dépend de votre configuration.
3. Mettez à jour vers 7.1.4 ou la version corrigée de votre branche, depuis Tableau de bord, puis Mises à jour.
4. Vérifiez la version obtenue. Un site peut afficher « à jour » alors que la mise à jour a échoué en silence.
5. Contrôlez les comptes administrateurs et les extensions : tout compte ou toute extension que vous ne reconnaissez pas est suspect.
6. Regardez les journaux d'accès à la recherche de requêtes répétées vers des fichiers PHP sous wp-content/upgrade/, surtout autour des moments où une mise à jour du cœur a eu lieu.
7. Si vous utilisez Wordfence, activez la protection étendue (Extended Protection) : un pare-feu qui tourne à l'intérieur de WordPress ne voit pas cette requête, puisqu'elle contourne WordPress. Selon Rescana, la règle correspondante n'arrive pour la version gratuite que le 27 novembre.

Autre point que je rappelle à mes clients : n'attendez pas d'être sûr d'être attaqué pour agir. Ce type de faille est exploité par des robots qui testent des milliers de sites par heure. L'attaquant ne sait rien de vous, il essaie simplement partout.

Comment savoir si mon site a déjà été attaqué ?

Cherchez trois choses : des requêtes répétées vers des fichiers PHP du dossier wp-content/upgrade/ dans les journaux, des comptes administrateurs que vous ne connaissez pas, et des extensions que personne n'a installées. Une trace dans les journaux prouve une tentative, pas une réussite.

Ce que l'on sait des indices, d'après l'analyse de Rescana :

Il faut être honnête sur une limite : Wordfence n'a publié que des signaux de comportement, pas de liste d'adresses ni d'empreintes de fichiers à rechercher. Aucune des sources officielles que j'ai consultées (CERT-FR, CISA) n'en fournit non plus. Il n'existe donc pas de liste toute faite à comparer. On part de ce qui est anormal sur le site : un compte, une extension, une date, plutôt que d'un nom précis.

Si vous trouvez quelque chose de suspect, ne nettoyez pas dans l'urgence. Faites d'abord une copie complète du site pour pouvoir comprendre ce qui s'est passé, puis restaurez une sauvegarde saine, changez tous les mots de passe, fermez les sessions ouvertes, et appliquez la mise à jour.

Ce que cette faille change pour la maintenance d'un site WordPress

Elle rappelle qu'une mise à jour n'est pas une opération anodine : c'est un moment sensible, qui mérite d'être préparé. Elle rappelle aussi que « mis à jour automatiquement » ne veut pas dire « suivi par quelqu'un ».

Beaucoup de professionnels que je rencontre ont la même idée : leur site est sous WordPress, il se met à jour tout seul, donc c'est réglé. Cette affaire montre les limites de ce raisonnement. La mise à jour automatique est très utile, et dans la plupart des cas c'est elle qui vous protégera ici. Mais elle ne vérifie pas que le dossier de travail est inaccessible, que la sauvegarde existe, que la version a bien changé, ou qu'un compte inconnu ne s'est pas glissé dans l'administration.

J'en retire quelques règles simples :

1. Garder les mises à jour automatiques de sécurité activées, et vérifier de temps en temps qu'elles le sont vraiment.
2. Avoir une sauvegarde hors du site, testée au moins une fois. Une sauvegarde qu'on n'a jamais restaurée est un espoir, pas une sauvegarde.
3. Verrouiller ce qui n'a pas à être public : un dossier de travail, un installateur, un fichier de configuration n'ont aucune raison d'être appelés depuis un navigateur.
4. Tenir un inventaire de tous les sites et de leurs versions, y compris les anciens.
5. Désigner quelqu'un qui lit les alertes. Les premières tentatives ont commencé le jour même de la sortie du correctif. Un avis du CERT-FR n'a d'effet que si quelqu'un le lit.

On retrouve ici une leçon que je tirais déjà de l'affaire UpdraftPlus et UpdraftCentral et des failles PHP2Shell : le délai entre le correctif et les premières attaques se compte en heures. Ce n'est plus le bon moment pour attendre le prochain créneau de maintenance du trimestre.

Faire vérifier et sécuriser votre site WordPress par un développeur

Si vous ne savez pas quelle version de WordPress tourne chez vous, ou si vous n'avez personne pour suivre ces alertes, je peux auditer votre site, le mettre à jour proprement et assurer sa maintenance, avec un devis gratuit sous 24 h.

Je développe des sites depuis une vingtaine d'années et je sais ce que représente un site vitrine ou une boutique en panne pour une entreprise. Pour ce type d'alerte, voici ce que je propose aux professionnels :

Si votre site est ancien, chargé d'extensions et difficile à maintenir, c'est peut-être le moment de le repenser : voir la création de site internet. Et si vous utilisez WordPress comme outil métier (espace client, suivi de dossiers, petit CRM), une application sur mesure réduit nettement la surface d'attaque.

Le plus simple : envoyez-moi l'adresse du site par le formulaire de contact ou appelez le 06 37 29 19 67. Je vous dis rapidement s'il est exposé et ce qu'il faut faire, que vous me confiiez la suite ou non.

Vos questions

Article publié le 5 novembre 2026.