WordPress 7.1.4 : 22 failles corrigées, vérifiez que votre site est à jour ⚠️

Que corrige WordPress 7.1.4 ?

WordPress 7.1.4 est une version de sécurité pure : elle ne contient aucune nouveauté, seulement des correctifs pour 22 vulnérabilités du cœur, regroupées en treize points dans l’annonce officielle. Elle arrive trois semaines après la 7.1.3, que nous avions détaillée dans notre article sur les sept failles corrigées par WordPress 7.1.3, et elle confirme un rythme soutenu de correctifs depuis la faille critique bouchée par la 7.1.2.

Les correctifs qui comptent le plus pour un propriétaire de site :

• Exécution de code à distance pendant une mise à jour : une faiblesse du processus de mise à jour du cœur pouvait permettre d’exécuter du code pendant la fenêtre où la mise à jour s’installe (signalée par Umut Bayram). Aucun détail technique n’a été publié.
• Une dizaine de failles XSS stockées : du code JavaScript malveillant enregistré dans un contenu puis exécuté dans le navigateur de la personne qui l’affiche. Elles touchent surtout l’Interactivity API (l’outil qui rend les blocs interactifs), l’outil de personnalisation et plusieurs blocs, et la plupart demandent au minimum un compte de contributeur.
• Fuite de brouillons de l’outil de personnalisation : des modifications non publiées faites dans Apparence > Personnaliser pouvaient être découvertes par un visiteur non connecté.
• Notes internes trop visibles : des rôles personnalisés chargés de modérer les commentaires pouvaient lire et modifier des notes sur des articles qui ne leur étaient pas ouverts.
• Déni de service via certaines liaisons de l’Interactivity API, et mise à jour des certificats racine embarqués après la révocation de l’autorité eMudhra.

Suivre ce flux de correctifs prend du temps, et c’est précisément ce que couvre notre maintenance WordPress : mises à jour testées, sauvegardes vérifiées et surveillance après chaque version.

Votre site est-il concerné ?

Oui, dès que votre site tourne avec une version antérieure à 7.1.4 sur la branche 7.1, ou antérieure au correctif de sa propre branche. Les correctifs ont été reportés sur toutes les branches encore maintenues, jusqu’à la 4.7, et publiés le même jour d’après la page des versions de WordPress.org :

• branche 7.1 : 7.1.4
• branche 7.0 : 7.0.8
• branche 6.9 : 6.9.11
• branche 6.8 : 6.8.12
• branches 6.7 et 6.6 : 6.7.11 et 6.6.11
• branches 6.5 à 6.3 : 6.5.14, 6.4.14 et 6.3.14

Selon la fiche de la version 7.1.4, les branches 7.0 et 6.9 sont touchées par les 22 failles, les plus anciennes par une partie seulement. Les versions 4.6 et antérieures ne reçoivent plus aucun correctif de sécurité : si votre site en est là, la question n’est plus de patcher mais de migrer.

Comment vérifier la version installée ?

Le plus rapide est de regarder en bas à droite de n’importe quelle page de l’administration, où WordPress affiche « Version 7.1.4 », ou d’ouvrir Tableau de bord > Mises à jour. Si vous n’avez plus accès à l’administration, la version est écrite dans le fichier wp-includes/version.php. Avec un accès SSH et WP-CLI (l’outil en ligne de commande officiel de WordPress) :

wp core version
grep "wp_version =" wp-includes/version.php

Pourquoi la mise à jour automatique ne s’est-elle pas faite ?

La plupart du temps, c’est qu’un réglage ou une extension bloque les mises à jour automatiques, car WordPress installe normalement seul les versions mineures comme 7.1.4. En intervention, nous retrouvons presque toujours l’une de ces causes :

• une constante dans wp-config.php : WP_AUTO_UPDATE_CORE réglée sur false, AUTOMATIC_UPDATER_DISABLED réglée sur true ou DISALLOW_FILE_MODS réglée sur true ;
• une extension de gestion des mises à jour ou un bout de code dans le thème qui utilise les filtres automatic_updater_disabled ou auto_update_core ;
• un dossier .git ou .svn à la racine, qui fait croire à WordPress que le site est versionné ;
• des droits de fichiers qui empêchent PHP d’écrire, reconnaissables au formulaire FTP qui s’affiche quand vous cliquez sur « Mettre à jour » ;
• un verrou resté en place après une mise à jour interrompue, signalé par le message « Une autre mise à jour est en cours ».

Pour trouver le coupable, commencez par ces recherches à la racine du site :

grep -nE "WP_AUTO_UPDATE_CORE|AUTOMATIC_UPDATER_DISABLED|DISALLOW_FILE_MODS" wp-config.php
grep -rnE "automatic_updater_disabled|auto_update_core" wp-content/mu-plugins wp-content/themes wp-content/plugins --include=*.php | head -20
ls -d .git .svn 2>/dev/null

L’outil Outils > Santé du site teste aussi les mises à jour automatiques en arrière-plan et indique en clair ce qui les bloque. Pour garder seulement les mises à jour mineures automatiques, qui sont celles qui apportent les correctifs de sécurité, la documentation officielle prévoit cette ligne dans wp-config.php :

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Si le message « Une autre mise à jour est en cours » s’affiche alors que rien ne tourne, notre fiche « Une autre mise à jour est en cours » explique comment supprimer le verrou sans risque.

Comment mettre à jour vers WordPress 7.1.4 sans casser le site ?

La méthode sûre tient en quatre étapes : sauvegarder, mettre à jour dans la même branche, contrôler l’intégrité des fichiers, puis vérifier le site.

1. Sauvegarder les fichiers et la base de données

Faites une sauvegarde complète avant toute manipulation, depuis l’interface de votre hébergeur ou votre extension de sauvegarde. En SSH, l’export de la base se fait ainsi :

wp db export avant-maj-7-1-4.sql

2. Lancer la mise à jour

Dans l’administration, ouvrez Tableau de bord > Mises à jour et cliquez sur « Mettre à jour maintenant ». En WP-CLI, l’option --minor décrite dans la documentation de wp core update reste dans votre branche, ce qui évite de sauter en 7.2 sans l’avoir voulu :

wp core update --minor
wp core version

3. Contrôler les fichiers du cœur

Cette commande compare chaque fichier du cœur à l’original publié par WordPress.org et signale ceux qui ont été modifiés ou ajoutés.

wp core verify-checksums

4. Vérifier le site et les comptes

Parcourez l’accueil, le formulaire de contact et, pour une boutique, le panier, puis videz les caches. Relisez aussi la liste des comptes, puisque la plupart des failles XSS corrigées demandent au moins un rôle de contributeur : supprimez ceux que vous ne reconnaissez pas.

wp user list --fields=ID,user_login,roles,user_registered

Si le site s’affiche mal après la mise à jour, suivez notre guide mise à jour WordPress et site cassé, et s’il reste bloqué sur le message de maintenance, celui sur WordPress bloqué en mode maintenance.