Ce que corrige la version du 28 octobre
Vous recevez une notification de mise à jour automatique pour un site vitrine. L’accueil fonctionne, mais le panneau de l’hébergeur affiche encore 7.1.3. Avant de relancer quoi que ce soit, identifiez le site concerné et le moment où chaque écran a relevé sa version. Un courrier peut concerner une copie de recette. Le panneau peut aussi afficher un inventaire collecté avant l’opération. Une lecture de la version sur l’installation active permet de décider s’il faut intervenir.
WordPress a publié la version de sécurité 7.1.4 le 28 octobre 2026 et a demandé une mise à jour rapide. Son avis décrit notamment un défaut pendant la mise à niveau, plusieurs possibilités d’injection de script stockée et des problèmes de contrôle d’accès liés à certaines données de l’éditeur. L’avis décrit des défauts corrigés dans le cœur. Il ne permet pas de déterminer à lui seul si un site particulier a été exploité. Une alerte d’accès suspect mérite sa propre investigation, même après l’installation du correctif.
Au relevé du 10 novembre 2026, l’archive officielle plaçait 7.1.4 dans la rubrique des versions stables les plus récentes. La branche 7.0 y présentait aussi 7.0.8, datée du même jour que 7.1.4. La présence de ce paquet dans l’archive ne donne aucune garantie sur le suivi à venir de cette branche. WordPress 7.2 figurait parmi les préversions. Consultez la rubrique stable au moment de votre intervention et suivez la version de sécurité appropriée à votre installation et à sa politique de maintenance. Si une version stable plus récente est déjà installée, conservez-la.
Repérer l’installation que vous devez contrôler
Commencez par le domaine public et le chemin de l’administration qui lui correspond. Dans un panneau d’hébergement, recherchez l’association entre ce domaine et son répertoire ou son environnement. Notez le nom affiché, la version relevée et l’heure. Une agence peut avoir trois entrées presque identiques pour le site principal, le clone de recette et l’ancienne installation de migration. Le bon identifiant est celui qui permet de relier l’adresse publique à l’environnement qui traite ses requêtes.
Si vous utilisez le tableau de bord, ouvrez directement l’administration du domaine voulu et vérifiez l’adresse après connexion. Relevez la version installée dans Tableau de bord → Mises à jour. Dans un réseau multisite, regardez aussi le tableau de bord de l’administration du réseau. Les sous-sites qui partagent le même cœur n’exigent pas chacun une copie différente des fichiers. Ils peuvent néanmoins présenter des usages différents, par exemple une boutique sur un sous-site et des formulaires sur un autre. Incluez les deux dans les contrôles de fonctionnement.
Une notification d’un service de maintenance peut avoir sa propre convention de nommage. Si vous ne savez pas quel site elle désigne, rapprochez son identifiant d’installation de celui du panneau. Pour un WordPress hébergé et maintenu par un tiers, demandez le numéro du cœur en production et l’heure du déploiement sur le domaine exact. Un statut général comme « maintenance terminée » ne précise pas toujours quelle version a été installée. Sur un service qui gère le cœur à votre place, passez par ce parcours au lieu de chercher à remplacer ses fichiers depuis une autre interface.
Préparer une sauvegarde que vous pourrez réutiliser
L’avis de sécurité appelle une intervention rapide. Prenez le temps nécessaire pour obtenir un point de retour utilisable, puis passez à la mise à jour. Identifiez la sauvegarde des fichiers et celle de la base, la date de leurs relevés et la personne qui peut les restaurer. Une copie limitée à la base ne remettra pas les fichiers du cœur en place. Une archive des fichiers ne récupérera pas une commande, une note ou une modification stockée dans la base. Le fichier de configuration contient des informations sensibles. Gardez vos copies hors des répertoires publics et réservez leur accès à l’équipe chargée du retour.
Pour une boutique, notez la dernière commande connue et le moment où commence l’intervention. Cette information évite de perdre les écritures récentes si une restauration devient nécessaire. Si le site reçoit beaucoup de modifications, coordonnez la fenêtre avec la personne qui gère les commandes ou les contenus. Décidez qui surveille le site et qui peut faire intervenir l’hébergeur. La fiche d’intervention doit indiquer où se trouve le point de retour, quels éléments il contient et à quel moment il a été pris.
Si une copie de recette est déjà disponible, utilisez-la pour tester les fonctions les plus importantes, comme un formulaire, un bloc interactif ou la page de connexion. Coupez les envois et traitements réels dans cette copie selon la procédure de votre hébergeur. Utilisez un paiement de test si le parcours en exige un. Conservez les résultats attendus avant la mise à jour. Si la copie montre déjà un problème, relevez-le afin de ne pas l’attribuer ensuite au correctif. Sur un petit site, quelques contrôles ciblés et un point de retour accessible sont souvent plus utiles qu’une longue liste générique.
Vérifier ou installer depuis le tableau de bord
Si le tableau de bord montre déjà la version stable de sécurité attendue, passez aux contrôles de fonctionnement. Votre hébergeur ou WordPress a pu effectuer l’opération en arrière-plan. Si la version est plus ancienne et que vous administrez directement le cœur, ouvrez Tableau de bord → Mises à jour et lisez l’offre affichée. Comparez le numéro et le type de version au canal stable. Regardez les notes de compatibilité de vos composants indispensables, surtout pour un passage depuis une ancienne branche qui change davantage de choses qu’un correctif ponctuel.
Un site peut afficher un écran de maintenance pendant la mise à jour. Relever une erreur pendant cette fenêtre ne suffit pas à déclarer l’échec. Gardez la sortie de l’opération et vérifiez son état avant de lancer une deuxième demande. Si l’interface indique qu’une autre mise à jour est en cours, vérifiez le travail en arrière-plan ou demandez au responsable du déploiement s’il est toujours actif. Vous évitez ainsi deux opérations concurrentes sur les mêmes fichiers.
Si les boutons manquent, cherchez d’abord qui possède le mécanisme de livraison. Un site dont le cœur est fourni par un paquet, une image de conteneur ou une recette de déploiement peut interdire les changements depuis le tableau de bord. Dans ce cas, la bonne intervention met à jour l’artefact de référence et le déploie avec le mécanisme habituel. Modifier un seul dossier sur le serveur pourrait donner une version correcte pendant quelques heures, jusqu’au prochain redéploiement de l’ancien paquet.
- Vérifiez que l’administration correspond au domaine et à l’environnement que vous venez de relever.
- Confirmez le point de retour. Si le panneau gère la mise à jour du cœur, suivez la procédure de ce panneau.
- Lancez la mise à jour stable appropriée depuis l’interface prévue et attendez le résultat.
- Revenez sur l’écran des mises à jour et relevez la version effectivement installée.
- Ouvrez une page publique et vérifiez le parcours principal choisi avant l’intervention.
Lire la version et vérifier les fichiers avec WP-CLI
Avec un accès au terminal, relevez le chemin du cœur à partir du panneau ou de la documentation de déploiement. Remplacez le chemin de l’exemple par le chemin confirmé. Exécutez d’abord wp core version. La réponse porte sur les fichiers qui se trouvent à cet emplacement. Si vous voyez un numéro inattendu, vérifiez que la commande lit le même répertoire que celui utilisé par le site public. Un clone plus récent dans un dossier voisin peut donner un résultat plausible sans renseigner la production.
Lorsque le dossier voulu correspond bien au paquet 7.1.4 en français de France, le second exemple demande à WP-CLI de comparer les fichiers du cœur aux sommes de contrôle de cette version et de cette variante. Adaptez les deux options au paquet installé. Un site dont l’administration est affichée en français peut utiliser des fichiers provenant d’un paquet d’une autre langue. Vérifiez la variante réellement déployée auprès de l’hébergeur ou dans votre procédure de construction. Sur une installation issue d’une version stable plus récente, utilisez son numéro. N’utilisez pas cet exemple pour réinstaller 7.1.4.
La commande de vérification lit les fichiers et consulte les sommes de contrôle de WordPress.org. Elle ne déclenche pas de mise à jour. Une concordance atteste seulement les fichiers que la commande a comparés dans ce répertoire. Elle ne contrôle ni la base, ni les extensions, ni les comptes, ni le serveur qui a effectivement répondu au navigateur. Un écart mérite une lecture précise du chemin signalé. Une variante de paquet différente, un déploiement incomplet ou une modification locale peuvent produire des écarts. Si les sommes de contrôle sont inaccessibles, consignez une vérification non aboutie et vérifiez la connectivité du serveur sans désactiver la validation TLS.
wp --path=/chemin/vers/wordpress core version
wp --path=/chemin/vers/wordpress core verify-checksums --version=7.1.4 --locale=fr_FRVérifier plusieurs serveurs ou plusieurs sites
Pour un site réparti sur plusieurs serveurs, prenez le déploiement comme unité de contrôle. Une connexion SSH peut vous amener sur un nœud seulement. Demandez au responsable de relever la version ou l’identifiant de l’artefact sur chaque groupe qui sert des requêtes. Faites inclure les instances ajoutées automatiquement et celles qui reviennent en service après une maintenance. Une image de déploiement ancienne peut remettre un nœud obsolète en ligne même quand les instances existantes sont à jour. Dans un déploiement par étapes, vérifiez aussi la fin du remplacement des anciennes instances.
Pour un portefeuille de sites, une ligne de suivi par installation suffit. Inscrivez le domaine, l’environnement, la version avant et après, l’heure du relevé, le mécanisme de déploiement et le nom du responsable du contrôle. Ajoutez un résultat pour la page publique et la fonction principale. Pour les sites qui partagent un même cœur, regroupez la version au niveau de ce cœur, puis relevez séparément les fonctions vérifiées sur les sous-sites. Cette distinction évite de cliquer plusieurs fois sur la même mise à jour tout en oubliant un usage critique du réseau.
Examinez les incohérences avant d’effacer les caches. Si le panneau affiche encore l’ancienne version alors que la production utilise un paquet vérifié, recherchez la date du dernier inventaire du panneau. Si un nœud sert encore un ancien paquet, faites corriger son déploiement. Une purge du cache de pages peut actualiser le HTML servi, mais elle ne remplace pas les fichiers PHP. Dans un site géré, transmettez les heures, versions et environnements observés à la personne qui peut relier le navigateur à l’infrastructure. Évitez d’utiliser un numéro récupéré dans le code HTML comme seule preuve de mise à jour.
Vérifier que les visiteurs peuvent encore agir
Ouvrez d’abord une page publique dans une fenêtre privée. Vérifiez le titre, les images utiles et la navigation. Puis effectuez l’action qui donne sa valeur au site. Pour un site de service, envoyez une soumission de test maîtrisée et confirmez sa réception. Pour une boutique, validez une commande de recette sur l’environnement prévu. Pour un magazine, ouvrez la prévisualisation d’un brouillon et vérifiez un bloc utilisé dans les articles publiés. Une page d’accueil servie depuis un cache peut fonctionner alors que l’administration ou un formulaire échoue.
Si votre site repose sur un bloc interactif, reproduisez une action identifiable avant et après l’intervention. Vérifiez par exemple le passage à la page suivante des commentaires avec le même article et le même navigateur. Si les équipes utilisent des notes sur des contenus, testez une note fictive avec les comptes prévus et vérifiez que chacun voit seulement ce que son rôle lui permet de voir. Ces tests portent sur le fonctionnement attendu. Ils ne consistent pas à tenter de reproduire les vulnérabilités décrites dans l’avis.
En cas d’échec, notez l’adresse, l’heure et l’action exacte. Vérifiez si le problème arrive avec un seul compte, un seul composant ou plusieurs pages. Comparez les journaux du site avec le moment du changement. Un formulaire peut échouer dans la recette parce que les sorties de courrier y sont volontairement désactivées. Dans ce cas, le test doit vérifier le comportement attendu dans cet environnement, par exemple un message capturé par le dispositif de recette. N’activez pas le transport de production pour rendre artificiellement le test positif.
Traiter un écart et préparer le retour
Si les fichiers diffèrent alors que le numéro a changé, gardez la liste des écarts et contrôlez la variante du paquet. Comparez ensuite le résultat à votre procédure de déploiement. Une modification de fichiers du cœur peut disparaître lors d’une mise à jour. Identifiez pourquoi elle existe avant de l’écraser. Si le cœur est livré par un artefact reproductible, redéployez depuis la source de référence corrigée par votre mainteneur. Si des fichiers inconnus ou une activité suspecte apparaissent, conservez les éléments utiles et faites examiner le site par le responsable de la sécurité. Une simple réinstallation du cœur ne traite pas les modifications qui touchent la base ou les extensions.
Si une fonction métier échoue après le correctif, cherchez d’abord si un composant précis est en cause et si une version compatible permet de conserver le cœur corrigé. Refaites le test sur une copie, avec une seule modification à la fois. Si le retour vers un état précédent devient nécessaire, faites valider ce choix avec la personne qui gère l’exploitation. Une restauration complète de la base peut supprimer des commandes et des publications arrivées depuis la sauvegarde. Relevez ces écritures et choisissez les éléments à récupérer avant toute restauration globale. Un retour vers un cœur vulnérable doit rester une mesure temporaire avec une reprise de la mise à jour dès que possible.
Vous pouvez clôturer l’intervention lorsque la version stable attendue correspond à l’installation qui répond au public et que les fonctions retenues ont été contrôlées. Consignez ce qui a été observé, qui a fait le contrôle et quels écarts restent ouverts. Pour un site géré, rattachez le résultat au rapport du mainteneur. Si vous ne pouvez vérifier qu’une partie des instances ou des sous-sites, indiquez lesquels. Ce relevé permet de reprendre précisément le contrôle après le prochain déploiement.
