Faille critique dans les mises à jour de WordPress (7.1.4) : ce qu’il faut vérifier sur votre site

Sécurité Jeudi 5 novembre 2026

Une faille qui permet de prendre la main sur un site sans aucun compte, cachée dans le mécanisme de mise à jour de WordPress lui-même : c’est la correction la plus importante de WordPress 7.1.4, publié le 28 octobre 2026. Les premières tentatives d’attaque ont été observées dans les heures qui ont suivi. Voici ce qu’il faut savoir, et ce qu’il faut vérifier si vous administrez vous-même votre site.

Ce qui s’est passé

Selon sa documentation officielle, la version 7.1.4 corrige 22 vulnérabilités. WordPress recommande de mettre à jour les sites « immédiatement ». Le CERT-FR a publié un avis le 29 octobre (CERTFR-2026-AVI-1420). Aucun identifiant CVE n’avait encore été attribué au moment où nous écrivons ces lignes.

La faille principale : une situation de concurrence (« race condition ») pendant les mises à jour du cœur, qui peut mener à une exécution de code à distance sans authentification. Elle a été signalée par le chercheur Umut Bayram.
Versions touchées : WordPress 4.7 à 7.1.3, d’après Wordfence, cité par le site Techaeris.
Gravité : score CVSS de 8,1, toujours selon Wordfence. L’attaque demande un timing précis, mais elle peut être automatisée.
Attaques observées : Wordfence indique avoir bloqué 62 969 tentatives d’exploitation dans les 24 heures qui ont suivi la publication de la 7.1.4, sans compromission réussie signalée.

Point important pour les utilisateurs de la version gratuite de Wordfence : selon Techaeris, la règle de pare-feu ne leur sera livrée que le 27 novembre, soit le délai habituel de 30 jours. D’ici là, seule la mise à jour de WordPress les protège.

Comment fonctionne la faille

Lors d’une mise à jour, WordPress décompresse les nouveaux fichiers dans un dossier temporaire situé sous wp-content/upgrade/. D’après l’analyse de Patchstack, avant la 7.1.4 :

le nom de ce dossier était prévisible, car il était dérivé du nom du paquet ;
le nettoyage supprimait le fichier index.php qui empêche d’afficher la liste du contenu du dossier.

Un attaquant qui vise le bon moment, pendant les quelques instants de la mise à jour, peut donc atteindre des fichiers qu’il n’aurait jamais dû voir. La version 7.1.4 ajoute 16 caractères aléatoires au nom du dossier, recrée index.php et ne le supprime plus. Elle exclut aussi wp-config.php des fichiers copiés pendant la mise à jour. Patchstack précise qu’une extension de sécurité écrite en PHP ne peut pas bloquer ce type d’attaque. La protection complémentaire se place au niveau du serveur web (voir plus bas).

Les autres correctifs

La plupart des autres failles corrigées sont des injections de script (XSS) stockées. Elles touchent l’Interactivity API, le balisage des blocs, l’outil de personnalisation (Customizer) ou encore le bloc Catégories, et plusieurs demandent un compte avec au moins le rôle Contributeur. S’y ajoutent l’exposition de modifications non publiées du Customizer à des visiteurs non connectés, et la mise à jour des certificats racines embarqués, en lien avec la compromission de certificats de l’autorité eMudhra.

Suis-je concerné ? Vérifier et mettre à jour

Toutes les branches qui reçoivent encore des correctifs de sécurité ont droit à une version corrigée. Selon la documentation de WordPress : 7.1.4, 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. L’annonce officielle précisait que ces versions pour les branches plus anciennes seraient publiées au fur et à mesure : vérifiez donc que la vôtre est bien disponible. Les versions 4.6 et antérieures ne reçoivent plus aucun correctif.

Avec WP-CLI :

# Version installée
wp core version

# Mise à jour, puis contrôle de l'intégrité des fichiers du cœur
wp core update
wp core verify-checksums

Sans WP-CLI, la version apparaît en bas de chaque page de l’administration, et la mise à jour se lance depuis Tableau de bord > Mises à jour. Si les mises à jour automatiques de sécurité sont actives, vérifiez quand même qu’elles ont bien eu lieu.

Au-delà de la mise à jour : trois vérifications

1. Contrôler le dossier wp-content/upgrade/. En temps normal, il est vide ou presque entre deux mises à jour. Un fichier PHP qui y traîne doit vous alerter :

ls -la wp-content/upgrade/
find wp-content/upgrade -type f -name '*.php' -ls

2. Bloquer l’accès web à ce dossier. Personne n’a besoin d’y accéder depuis un navigateur. Sous Nginx :

location ^~ /wp-content/upgrade/ {
    deny all;
}

Sous Apache, dans le fichier .htaccess à la racine du site (avant les règles de WordPress) :

RedirectMatch 403 ^/wp-content/upgrade/
Options -Indexes

Testez ensuite avec curl -I https://votre-site.fr/wp-content/upgrade/ : la réponse doit être un code 403.

3. Revoir les comptes utilisateurs. Plusieurs failles corrigées sont exploitables à partir du rôle Contributeur. Supprimez les comptes inutiles, et repérez tout administrateur que vous ne connaissez pas :

wp user list --role__in=administrator,editor,author,contributor --fields=ID,user_login,roles,user_registered

Au moindre doute, comme un fichier inconnu ou un compte suspect, traitez le site comme compromis : isolez-le, changez les mots de passe et les clés de salage de wp-config.php, puis restaurez une sauvegarde saine.

Notre avis d’agence

D’habitude, nous répétons que la porte d’entrée sur WordPress est rarement le cœur du CMS, et bien plus souvent une extension. Cette fois, c’est le cœur, et plus précisément l’outil censé vous protéger : la mise à jour. Le message reste le même. Un site WordPress se protège par des mises à jour rapides, mais aussi par une configuration serveur qui ne laisse rien d’inutile accessible depuis le web. Les deux se complètent.

La prochaine version majeure, WordPress 7.2, est prévue pour le 8 décembre. Vous ne savez pas quelle version tourne sur votre site, ou vous préférez que nous nous en occupions ? Contactez-nous : nous pouvons vérifier votre installation et mettre en place le durcissement décrit ici.

Sources

Mots-clés