WordPress 7.1.4 est sorti le 28 octobre 2026 : c’est une version de sécurité, et wordpress.org recommande de mettre à jour vos sites immédiatement. Trois semaines à peine après la 7.1.3, elle corrige une série de failles dont une, plus inhabituelle, touche le cœur du processus de mise à jour lui-même. Voici ce que j’en retiens pour les sites WordPress que je maintiens, et ce que vous devez vérifier.

Ce qui change

L’annonce officielle de WordPress 7.1.4 liste douze problèmes de sécurité, plus une mise à jour des certificats racine embarqués. Patchstack, qui a analysé la version, compte 22 vulnérabilités réparties en 17 avis. Les points qui comptent pour un site en production :

  • Exécution de code à distance pendant la fenêtre de mise à jour. C’est la faille la plus sérieuse. D’après Patchstack, avant la 7.1.4, le dossier temporaire d’extraction dans wp-content/upgrade/ avait un nom prévisible, et son index.php était supprimé au nettoyage. Un attaquant non connecté qui tombe sur le bon chemin pendant les quelques secondes d’une mise à jour pouvait en profiter. La 7.1.4 ajoute 16 caractères aléatoires au nom du dossier, rétablit l’index.php et empêche la copie de wp-config.php hors du répertoire de travail.
  • Une dizaine de failles XSS stockées : balisage de blocs, demandes de suppression de données personnelles, Interactivity API, Customizer, blocs Catégories, Playlist, image et pagination des commentaires, identifiants utilisateur spécialement conçus.
  • Fuites d’informations : brouillons du Customizer découvrables sans être connecté, et notes lisibles par des utilisateurs qui n’ont pas le droit de modifier l’article concerné.
  • Déni de service stocké dans l’Interactivity API.
  • Certificats racine mis à jour après la révocation d’eMudhra.

Les correctifs sont rétroportés sur toutes les branches encore éligibles, jusqu’à WordPress 4.7. Patchstack cite notamment 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 et 4.7.39. En dessous de 4.7, plus rien.

Ce qui peut casser

Sur une version de sécurité comme celle-ci, le risque de casse est faible, mais je regarde toujours trois choses :

  • Les blocs et thèmes personnalisés. La plupart des failles corrigées sont des XSS dans des blocs : les correctifs renforcent l’échappement du contenu. Un bloc maison qui injecte du HTML de façon peu orthodoxe peut s’afficher différemment. Vérifiez les pages qui en utilisent.
  • Les scripts qui touchent à wp-content/upgrade/. Le nom du dossier temporaire est désormais aléatoire. Un script de déploiement ou un outil maison qui comptait sur un chemin fixe devra être adapté.
  • Les appels HTTP sortants. La mise à jour des certificats racine suit la révocation d’eMudhra. Si votre site interroge une API dont le certificat dépend de cette autorité, l’appel peut échouer : surveillez les erreurs de connexion dans les logs après la mise à jour.

Faut-il mettre à jour maintenant ?

Oui. C’est une version de sécurité sur la branche actuelle, sans nouvelle fonctionnalité : il n’y a aucune raison d’attendre.

Il faut tout de même relativiser la faille d’exécution de code. Patchstack la classe en complexité d’attaque élevée et juge son exploitation peu pratique : la fenêtre ne dure que quelques secondes et l’attaquant doit viser le bon chemin au bon moment. Mais cette fenêtre revient à chaque mise à jour, y compris les mises à jour automatiques, et le code concerné remonte à WordPress 2.8. Les autres failles demandent presque toutes un compte Contributeur ou plus : elles concernent surtout les sites avec plusieurs auteurs, une boutique avec des comptes clients ou un espace membres.

  • Mises à jour automatiques actives : votre site est probablement déjà en 7.1.4. Vérifiez-le dans Tableau de bord > Mises à jour.
  • Site resté sur une ancienne branche (7.0, 6.9…) : installez au minimum la version corrective de votre branche. Mais wordpress.org le rappelle : seule la dernière version est réellement supportée.
  • Site en 4.6 ou plus ancien : aucun correctif. Là, ce n’est plus une mise à jour, c’est un chantier. Voir site WordPress piraté : que faire si vous avez déjà des doutes.

Pensez aussi au serveur : PHP a publié le 21 octobre un correctif critique pour deux failles d’exécution de code à distance. Mettre WordPress à jour sans mettre PHP à jour laisse une porte ouverte. Tout est expliqué dans mon article sur la faille critique PHP CVE-2026-109618.

Checklist avant de mettre à jour

  1. Sauvegarde complète (fichiers et base de données), stockée hors du serveur.
  2. Mettez à jour WordPress en 7.1.4 (ou la version corrective de votre branche), puis le thème et les extensions.
  3. Bloquez l’accès web à wp-content/upgrade/. C’est la mesure recommandée par Patchstack en complément, car un pare-feu applicatif en PHP ne peut pas filtrer cette requête. Sous Apache, un fichier .htaccess dans ce dossier suffit : 
    Require all denied

    Sous Nginx, dans le bloc server :

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

    WordPress n’a pas besoin d’accès web à ce dossier pour se mettre à jour.

  4. Vérifiez que le dossier n’est pas listable en ouvrant son adresse dans un navigateur : vous devez obtenir une erreur 403.
  5. Faites le ménage dans les comptes : qui a encore un rôle Contributeur, Auteur, Éditeur ou Administrateur ? Supprimez les comptes inutiles et rétrogradez les autres.
  6. Contrôlez la version de PHP dans Outils > Santé du site : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 minimum selon votre branche.
  7. Parcourez les pages clés (accueil, formulaires, panier, pages avec blocs personnalisés) et jetez un œil au log d’erreurs PHP.

Ma méthode complète est dans la checklist de maintenance WordPress. Si le site affiche une erreur après la mise à jour, voir réparer l’erreur critique WordPress.

Questions fréquentes

Comment savoir si mon site est déjà en WordPress 7.1.4 ?

Dans l’administration, menu Tableau de bord > Mises à jour : la version installée y est affichée. Vous la trouvez aussi dans Outils > Santé du site > Informations.

Mon site a-t-il pu être piraté par cette faille ?

C’est peu probable, vu la difficulté d’exploitation décrite par Patchstack. Mais si vous voyez des fichiers inconnus dans wp-content/upgrade/, un administrateur que vous n’avez pas créé ou des redirections étranges, faites vérifier le site. Je propose un audit WordPress et un dépannage WordPress pour ces cas-là.

Et WordPress 7.2 ?

WordPress 7.2 est en bêta et sa sortie est prévue le 8 décembre 2026. La bêta 3 contient déjà les correctifs de la 7.1.4. Comme pour toute version majeure, j’attends en général quelques jours et je teste sur une copie avant de l’installer en production. En attendant, la 7.1.4 est la version à avoir. Pour la question de la version de PHP à utiliser avec WordPress, voir WordPress et PHP : quelle version utiliser ?