WordPress 7.0.2 : vérifier la mise à jour de sécurité en PME

WordPress 7.0.2 a apporté le 17 juillet 2026 les correctifs de sécurité décrits dans la publication officielle. Elle n’est plus la version courante : l’archive WordPress.org liste 7.0.3 comme dernière version de la branche 7.0, publiée le 6 août 2026. Avant d’intervenir, identifiez la version réellement déployée, vérifiez que vous disposez d’une sauvegarde exploitable, appliquez la version courante correspondant à votre branche, puis testez les parcours essentiels du site. Une mise à jour automatique activée ne constitue pas, à elle seule, une preuve que le site est corrigé et fonctionne correctement.

Le 17 juillet 2026, WordPress a publié la version 7.0.2 pour corriger un problème de sécurité critique et un autre de gravité élevée. L’équipe WordPress recommande une mise à jour immédiate et indique avoir activé les mises à jour forcées pour les sites utilisant des versions affectées. Cette alerte ne permet toutefois pas d’affirmer à distance qu’un site précis est vulnérable, corrigé ou compromis : il faut vérifier son environnement réel.

Voici la méthode en huit étapes pour passer de l’alerte à un contrôle documenté.

Pourquoi vérifier WordPress 7.0.2 maintenant

L’annonce officielle de WordPress 7.0.2 décrit deux problèmes de sécurité : une injection SQL facilitée et une confusion de route dans l’API REST associée à une injection SQL pouvant mener à une exécution de code à distance. WordPress classe l’un des problèmes comme critique et l’autre comme élevé.

Les identifiants publiés sont CVE-2026-60137 et CVE-2026-63030. Ils servent à retrouver et suivre les avis techniques ; ils ne remplacent pas la vérification de la version présente sur chaque site.

WordPress précise aussi les branches corrigées :

Le dernier point est important : « non concernée par ces deux vulnérabilités » ne signifie pas « version ancienne sûre ». Un site peut présenter d’autres faiblesses liées au cœur, aux extensions, au thème, à l’hébergement ou aux accès. La checklist ci-dessous traite cette mise à jour précise, pas un audit de sécurité complet.

Étape 1 — Inventorier les sites et leurs responsables

Une PME peut avoir plus d’installations WordPress qu’elle ne le pense : site principal, ancienne campagne, sous-domaine, espace de test, boutique, microsite géré par un prestataire. Commencez par dresser une liste simple :

• domaine et sous-domaines ;
• environnement de production ou de test ;
• hébergeur et mode d’administration ;
• personne responsable de la décision ;
• personne ou prestataire autorisé à intervenir ;
• criticité du parcours : présentation, formulaire, réservation, paiement, espace connecté.

L’objectif n’est pas de produire un inventaire parfait avant d’agir. Il est d’éviter qu’un site oublié reste sans propriétaire ou qu’une mise à jour soit lancée simultanément par deux intervenants.

Étape 2 — Confirmer la version réellement déployée

Le réglage « mises à jour automatiques activées » décrit une configuration. Il ne prouve pas que la mise à jour a abouti. Un problème de droits, de tâche planifiée ou de communication avec WordPress.org peut empêcher son exécution.

Vérifiez la version dans l’administration autorisée du site, généralement depuis Tableau de bord > Mises à jour, ou depuis l’outil de gestion fourni par l’hébergeur. Sur une infrastructure administrée, un opérateur habilité peut utiliser l’outil de ligne de commande déjà prévu par la procédure interne. Conservez un relevé daté indiquant le domaine, l’environnement et la version constatée.

Si vous n’avez pas les accès ou les compétences nécessaires, ne cherchez pas à les contourner. Demandez au responsable technique ou à l’hébergeur de fournir l’état de version et la preuve de l’intervention.

Étape 3 — Vérifier la sauvegarde et la possibilité de restauration

La documentation officielle sur la mise à jour de WordPress recommande de sauvegarder le site avant de commencer afin de pouvoir le restaurer en cas de problème.

Pour être utile, la sauvegarde doit être identifiable : date, périmètre, emplacement, politique de conservation et personne capable de lancer la restauration. Selon l’architecture, le périmètre peut comprendre la base de données, les fichiers du site, les médias, la configuration et les éléments nécessaires au redémarrage du service.

Une archive présente dans un tableau de bord n’est pas encore une restauration prouvée. Pour un site critique, prévoyez un test de restauration sur un environnement distinct ou, au minimum, une procédure documentée et validée par la personne qui interviendra en cas d’échec.

Étape 4 — Choisir le correctif correspondant à la branche

La bonne cible dépend de la version réellement observée. Au 11 août 2026, l’archive officielle liste 7.0.3 pour la branche 7.0, 6.9.6 pour la branche 6.9 et 6.8.7 pour la branche 6.8. Les versions 7.0.2, 6.9.5 et 6.8.6 restent les correctifs annoncés le 17 juillet pour les problèmes décrits, mais ne sont plus les dernières versions de leurs branches.

Ne choisissez pas une version au hasard et ne profitez pas de l’alerte pour regrouper plusieurs changements sans rapport. Une montée de branche, une évolution de PHP, le remplacement d’un thème et une mise à jour de sécurité n’ont pas les mêmes risques ni le même plan de retour. Si plusieurs travaux sont nécessaires, séparez-les autant que possible pour rendre les anomalies compréhensibles.

Étape 5 — Mettre à jour dans une fenêtre contrôlée

La documentation WordPress prévoit une mise à jour en un clic pour la plupart des sites et une procédure manuelle lorsque cela est nécessaire. Le choix de la méthode dépend de l’hébergement, des droits disponibles et de la complexité du site.

Avant l’intervention, notez :

• le responsable qui donne le feu vert ;
• l’opérateur qui exécute la mise à jour ;
• l’heure de début et la fenêtre de contrôle ;
• les personnes à prévenir si le formulaire, le paiement ou la connexion échoue ;
• le seuil de décision pour restaurer la sauvegarde.

Pour un site complexe ou directement générateur de chiffre d’affaires, testez d’abord sur un environnement de préproduction représentatif lorsqu’il existe. Cette précaution ne doit pas servir de prétexte à retarder indéfiniment un correctif urgent : adaptez la profondeur du test à la criticité et à la capacité réelle de retour arrière.

Étape 6 — Tester les parcours qui produisent de la valeur

Le message « mise à jour terminée » indique que l’opération technique est arrivée à son terme. Il ne démontre pas que les visiteurs peuvent encore accomplir leurs tâches.

Construisez une courte liste de contrôles adaptée au site :

• page d’accueil et pages d’atterrissage principales ;
• navigation sur mobile et ordinateur ;
• formulaire de contact, message de confirmation et réception côté équipe ;
• connexion, réinitialisation du mot de passe et espace client, le cas échéant ;
• recherche interne, filtres ou fonctions métier ;
• réservation ou commande en mode de test ;
• paiement uniquement selon la procédure de test autorisée ;
• emails transactionnels ;
• balises analytics et événements essentiels ;
• absence d’erreur visible sur les pages prioritaires.

Videz ou actualisez les caches selon la procédure de l’hébergeur avant de conclure qu’une ancienne version est encore servie. La documentation WordPress recommande de vider le cache à la fin d’une mise à jour lorsqu’un système de cache est activé.

Étape 7 — Contrôler les erreurs sans conclure trop vite

Après la mise à jour, examinez les erreurs fonctionnelles, les alertes de l’hébergeur et les journaux auxquels vous êtes légitimement autorisé à accéder. Comparez les observations avant et après l’intervention : hausse d’erreurs serveur, tâche planifiée en échec, formulaire non reçu, extension incompatible ou page anormalement lente.

L’absence d’erreur visible ne permet pas d’affirmer qu’un site n’a jamais été compromis. Inversement, une erreur après mise à jour ne prouve pas une attaque. Si des signes anormaux apparaissent, conservez les éléments disponibles, limitez les changements improvisés et faites qualifier l’incident par une personne compétente.

Étape 8 — Conserver la preuve et planifier le suivi

Un compte rendu de mise à jour peut tenir sur une page. Il devrait indiquer :

• le domaine et l’environnement ;
• les versions avant et après ;
• la date, l’opérateur et le valideur ;
• la sauvegarde associée ;
• les parcours testés et leur résultat ;
• les anomalies ouvertes ;
• la prochaine date de contrôle.

Cette trace évite de recommencer l’enquête à la prochaine alerte. Elle transforme la maintenance WordPress en processus d’exploitation, avec un responsable et une preuve, plutôt qu’en suite de clics difficiles à reconstituer.

Comment gérer plusieurs sites WordPress sans perdre le contrôle

Pour plusieurs installations, utilisez un tableau unique et traitez les sites par niveau de criticité. Commencez par les environnements exposés et les parcours essentiels, puis suivez chaque domaine jusqu’à un état clair : version vérifiée, sauvegarde identifiée, correctif appliqué, tests terminés ou blocage documenté.

Un outil de gestion centralisée peut accélérer la collecte et le déploiement, mais il ne remplace ni le responsable désigné ni les tests propres à chaque site. Une mise à jour groupée réussie peut masquer un défaut qui n’existe que sur une boutique ou un formulaire particulier.

FAQ sur la mise à jour WordPress 7.0.2

Les mises à jour forcées suffisent-elles ?

Non comme preuve de contrôle. WordPress a activé les mises à jour forcées pour les versions affectées et les sites compatibles peuvent lancer le processus automatiquement. Il reste nécessaire de vérifier la version réellement installée et le fonctionnement des parcours essentiels.

Les versions antérieures à WordPress 6.8 sont-elles concernées ?

WordPress indique qu’elles ne sont pas affectées par les deux vulnérabilités corrigées dans cette publication. Cela ne permet pas de conclure qu’une ancienne version est sûre, maintenue ou exempte d’autres vulnérabilités.

Faut-il aussi tester les extensions et le thème ?

Oui, au niveau fonctionnel. Même lorsque la mise à jour vise le cœur de WordPress, le thème et les extensions participent aux formulaires, paiements, connexions et affichages. Le contrôle après mise à jour doit donc couvrir les fonctions qu’ils rendent possibles.

Que faire si la mise à jour échoue ?

N’enchaînez pas des manipulations non documentées sur la production. Relevez le message d’erreur, vérifiez la procédure officielle et le plan de retour, puis sollicitez l’hébergeur ou le prestataire habilité si nécessaire. La documentation WordPress contient des étapes de dépannage, mais leur exécution doit rester adaptée aux accès et aux compétences disponibles.

Passez de l’alerte à un état de version vérifiable

Active Digital peut cadrer l’inventaire, la sauvegarde, la mise à jour et les tests de contrôle de vos sites WordPress. L’objectif n’est pas de déclarer un site sain sans preuve : il est de produire un état daté, des écarts visibles et un plan de suivi adapté à votre environnement.

CTA : Demandez un état de version daté et un plan de contrôle de vos sites WordPress.

Sources externes

1. WordPress.org, WordPress 7.0.2 Release, 17 juillet 2026, contrôlé le 11 août 2026 — gravités, recommandation de mise à jour, mises à jour forcées, branches corrigées et identifiants CVE/GHSA.
2. WordPress.org, Release Archive, contrôlé le 11 août 2026 — dernière version 7.0.3 publiée le 6 août 2026 ; branches 6.9.6 et 6.8.7 publiées à la même date.
3. WordPress.org, Download WordPress, contrôlé le 11 août 2026 — téléchargement courant relié à la dernière version stable.
4. WordPress en Français, Comment mettre à jour WordPress, contrôlé le 11 août 2026 — sauvegarde préalable, mise à jour automatique ou en un clic, cache, restauration et dépannage.
5. WordPress.org Documentation, Site Health screen, contrôlé le 11 août 2026 — contrôle du fonctionnement des mises à jour en arrière-plan.