WordPress 7.1.4 corrige une faille pendant la mise à niveau : vérifiez chaque site

WordPress a publié la version 7.1.4 le 28 octobre 2026 avec des correctifs de sécurité, dont celui d'une faiblesse pouvant permettre l'exécution de code à distance pendant la fenêtre de mise à niveau. L'annonce de publication recommande une mise à jour immédiate. Pour les propriétaires de plusieurs sites, la première tâche consiste à établir quelles installations ont réellement reçu le correctif.

Selon WordPress, les sites compatibles avec les mises à jour automatiques en arrière-plan démarrent le processus automatiquement. Cela décrit le début d'une mise à jour, pas la confirmation de son achèvement sur chaque serveur. Un réglage activé, une ancienne liste de maintenance ou la politique générale d'un hébergeur ne remplace pas la vérification de la version installée.

Le processus de mise à niveau fait lui-même partie du correctif

L'annonce attribue à Umut Bayram le signalement de la faiblesse du processus de mise à niveau. Elle énumère aussi des problèmes de scripts intersites stockés, ou XSS stockées, touchant notamment l'Interactivity API, le rafraîchissement sélectif de l'outil de personnalisation et les demandes de suppression de données personnelles, ainsi qu'un déni de service stocké. Les certificats racines fournis sont mis à jour à la suite de la révocation eMudhra.

D'autres correctifs portent sur la découverte sans authentification de jeux de modifications non publiés de l'outil de personnalisation et sur l'accès aux notes d'un article par des utilisateurs privilégiés qui ne peuvent pas modifier l'article concerné. Ce sont des problèmes distincts de permissions et d'exposition. L'annonce n'établit ni qu'un site précis a été attaqué ni que toutes les failles ont les mêmes conditions d'exploitation.

La documentation de la version précise les composants et permissions concernés. Elle aide l'administrateur qui évalue une installation particulière. Pour le propriétaire qui doit décider d'agir, la recommandation de mise à jour immédiate est déjà claire ; la faille pendant la mise à niveau n'est pas une raison de différer la réparation.

Vérifiez l'achèvement, puis le fonctionnement du site

Ouvrez le Tableau de bord de chaque site, choisissez Mises à jour et consultez la version actuelle. Pour la branche stable en cours, la cible de cette publication est 7.1.4. Si la mise à jour reste proposée, utilisez Mettre à jour maintenant ou organisez l'intervention avec la personne responsable de l'hébergement. Rouvrez l'écran après la fin du processus et consignez la version obtenue.

Les instructions de mise à jour de WordPress recommandent une sauvegarde préalable et expliquent que les échecs de mise à jour en un clic peuvent être liés aux permissions du système de fichiers. Un suivi de maintenance utile doit donc inclure le site, la version installée, l'emplacement de la sauvegarde, le résultat et toute erreur non résolue. Une mise à jour échouée doit rester dans la liste des tâches actives, pas dans la colonne des travaux terminés.

Après la mise à jour, vérifiez un article public, l'accès administrateur et une action de publication essentielle. Ces contrôles établissent si le site reste utilisable ; ils ne constituent pas un audit de sécurité. Utilisez un plan préparé de préproduction et de retour arrière, et assurez-vous que les vérifications de sauvegarde et de restauration couvrent une récupération réellement exécutable.

Les anciennes branches exigent une version précise

L'annonce indique que les rétroportages de sécurité s'étendent jusqu'à la branche 4.7 et que leur diffusion était encore en cours. La documentation de la version recense désormais des versions anciennes corrigées, dont 4.7.39, tout en précisant que 4.6 et les versions antérieures ne reçoivent plus de mises à jour de sécurité. Seule la dernière version de WordPress bénéficie d'un support actif. Vérifiez le correctif indiqué pour la branche réellement installée ; l'existence de rétroportages ne sécurise pas toutes les anciennes installations.

Si un site ne peut pas être mis à jour aujourd'hui, contactez son hébergeur ou son responsable de maintenance avec la version et l'erreur bloquante, désignez une personne responsable et fixez un délai concret de récupération ou de mise à niveau. Demandez une évaluation des mesures de limitation du risque adaptée au site pendant l'organisation de la réparation. Ne considérez pas une sauvegarde, un pare-feu ou une promesse de mise à jour ultérieure comme la preuve que ces vulnérabilités sont corrigées.

La même annonce indique que 7.2 Beta 3 contient les correctifs applicables et donne le 8 décembre comme date prévue de publication de 7.2. Les archives des versions distinguent les tests bêta des versions de production. Une future version majeure ne justifie pas de laisser en attente une mise à jour de sécurité actuelle.