WordPress 7.1.4 : 22 failles corrigées, dont une qui profite de la mise à jour elle-même

Le 28 octobre, WordPress 7.1.4 a corrigé 22 failles d’un coup. L’une d’elles est vicieuse : elle profite des quelques secondes où votre site se met à jour. Si vous avez un site WordPress pour votre commerce ou votre cabinet, cette faille WordPress vous concerne, même si les mises à jour automatiques sont activées. Voici ce qu’elle change, et ce que vous pouvez vérifier vous-même aujourd’hui.

Ce que corrige WordPress 7.1.4, en clair

WordPress 7.1.4 est sorti le 28 octobre 2026. Cette version ne change rien à l’apparence de votre site : elle bouche des trous. WordPress.org recense 22 vulnérabilités corrigées, que Patchstack regroupe en 17 avis de sécurité. La version précédente, la 7.1.3, en corrigeait sept.

La plupart de ces failles demandent un compte sur le site pour être exploitées. Les autres sont plus ennuyeuses, parce qu’un simple visiteur peut s’en servir.

Deux de ces failles ont été signalées par Anthropic, l’éditeur de Claude, dont une dans l’écran des demandes d’effacement de données personnelles.

Toutes les versions ne sont pas touchées de la même façon

Plus votre version est récente, plus elle contient de code concerné. WordPress.org donne le détail :

• les branches 7.0 et 6.9 sont touchées par les 22 failles ;
• les branches 6.8 et 6.7 par 20 failles ;
• les branches 6.5 et 6.4 par 17 failles ;
• les branches 4.8 et 4.7 par 2 failles seulement.

Ce que ça ne veut pas dire

Une faille corrigée n’est pas un site piraté. C’est une fenêtre que l’on referme. Le risque commence quand la fenêtre reste ouverte des semaines après la sortie du correctif, parce que les pirates lisent les mêmes notes de version que nous.

Un correctif publié, c’est aussi le plan de la serrure distribué à tous les curieux.

La faille qui se glisse pendant la mise à jour

Imaginez un serrurier qui change la serrure de votre boutique. Pendant qu’il travaille, la porte reste entrouverte. Quelques secondes seulement, mais quelqu’un qui guette au bon moment peut entrer. C’est exactement ce que corrige WordPress 7.1.4.

Ce qui se passe pendant ces quelques secondes

Quand WordPress se met à jour, il décompresse la nouvelle version dans un dossier de travail, wp-content/upgrade. Patchstack et Wordfence décrivent le problème en trois points :

1. ce dossier portait un nom facile à deviner ;
2. le nettoyage supprimait le fichier index.php qui empêche d’en afficher le contenu ;
3. si le dossier est accessible depuis le web, un attaquant peut y lancer du code PHP pendant la fenêtre de mise à jour.

Aucun compte n’est nécessaire. La faille porte un score CVSS de 8,1 sur 10, soit un niveau élevé. Patchstack juge toutefois son exploitation peu pratique : il faut viser une fenêtre de quelques secondes, sur un serveur qui laisse ce dossier ouvert.

Les attaques ont commencé tout de suite

Peu pratique ne veut pas dire ignoré. D’après The Hacker News, Wordfence a bloqué 62 969 tentatives d’attaque en 24 heures dans les jours qui ont suivi le correctif. Ce sont des tentatives, pas des sites piratés, mais elles montrent que des robots testent déjà les sites en masse.

WordPress 7.1.4 referme la porte de trois façons :

• le dossier de travail reçoit 16 caractères aléatoires dans son nom ;
• le fichier index.php est recréé ;
• le fichier wp-config.php, qui contient les accès à votre base de données, n’est plus copié.

La fenêtre se rouvre à chaque mise à jour, y compris les mises à jour automatiques. Le correctif la rend plus difficile à trouver, la fermeture côté serveur la rend inutile.

Votre site est-il exposé ? Cinq vérifications en cinq minutes

Pas besoin d’être informaticien. Une boulangère qui a fait faire son site il y a trois ans peut faire ces contrôles entre deux fournées. Il suffit d’un accès administrateur à WordPress.

1. Regardez votre version. Dans le tableau de bord, menu Tableau de bord puis Mises à jour, WordPress affiche le numéro installé. Il doit correspondre à une version corrigée du tableau ci-dessous.
2. Vérifiez que la mise à jour automatique est passée. Les sites dont les mises à jour automatiques sont activées reçoivent le correctif sans intervention. Mais une extension, un hébergeur ou un ancien réglage peuvent les bloquer : le numéro affiché fait foi.
3. Posez une question à votre hébergeur. Demandez-lui si le dossier wp-content/upgrade est fermé aux visiteurs et si l’affichage du contenu des dossiers est désactivé. Patchstack le rappelle : un pare-feu installé dans WordPress ne protège pas contre cette faille, la fermeture se règle sur le serveur.
4. Faites le tri dans les comptes. La plupart des autres failles demandent un compte Contributeur ou plus. Un paysagiste qui a ouvert un accès à un rédacteur l’an dernier doit le supprimer s’il ne sert plus.
5. Cherchez ce qui n’a rien à faire là. Un administrateur que vous ne connaissez pas, une extension que vous n’avez pas installée : ce sont les signes d’une intrusion. Dans ce cas, ne supprimez rien seul, faites d’abord une sauvegarde.

Quelle version corrigée pour votre site

Si votre site tourne encore sur une vieille version

Les correctifs existent jusqu’à la branche 4.7, mais WordPress.org rappelle que seule la dernière version est vraiment suivie. Un site resté en 4.6 ou avant n’a plus de serrure de rechange. Là, la question n’est plus la mise à jour mais la refonte.

Quatre correctifs en six semaines : la maintenance passe à l’heure hebdomadaire

WordPress 7.1.4 n’arrive pas seul. C’est la quatrième mise à jour de sécurité de la branche 7.1 en six semaines.

En juillet, la faille wp2shell avait déjà poussé WordPress à forcer les mises à jour des sites. Et la version 7.2 est annoncée pour le 8 décembre.

Pourquoi une fois par mois ne suffit plus

Avec ce rythme, un site mis à jour le premier lundi du mois peut rester trois semaines avec une porte connue de tous. Selon Webhosting.today, 64,4 % des installations tournent sur la branche 7.1, ce qui laisse plus d’un tiers des sites sur des versions plus anciennes.

Les mises à jour automatiques aident, mais elles ne voient pas tout :

• elles ne vérifient pas qu’une extension n’a pas cassé une page ;
• elles ne règlent pas le serveur ;
• elles ne suppriment pas les comptes oubliés ;
• elles ne font pas de sauvegarde avant de toucher au site.

Ce que je fais chez mes clients

Dans ma maintenance WordPress, je passe les mises à jour chaque semaine, je sauvegarde le site toutes les deux semaines, et je dépanne quand une extension bloque le site après une mise à jour. Si votre site tourne sous Divi, les mises à jour du thème méritent la même attention : je l’explique dans l’article sur le passage à Divi 5.

Un site WordPress, c’est comme une vitrine sur rue : on ne vérifie pas le rideau de fer une fois par mois.

Faille WordPress : la mise à jour ne suffit que si la porte est fermée

WordPress 7.1.4 corrige 22 failles, dont une qui se glisse dans la mise à jour elle-même. Vérifiez votre numéro de version, demandez à votre hébergeur de fermer le dossier de mise à jour et supprimez les comptes qui ne servent plus. Avec quatre correctifs en six semaines et la version 7.2 attendue le 8 décembre, la vraie question n’est plus de savoir si votre site sera mis à jour, mais à quel rythme.

Vous ne savez pas où en est votre site ? Demandez votre premier audit offert.