WordPress 7.0.2 est une mise à jour de sécurité urgente publiée le 17 juillet 2026. Installez-la immédiatement depuis Tableau de bord, Mises à jour, puis vérifiez la version affichée dans le pied de page de l’administration. Cette version corrige deux vulnérabilités, dont une injection SQL critique liée à une confusion de routes REST pouvant mener à une exécution de code à distance. Les branches 6.9 et 6.8 disposent aussi de correctifs, respectivement WordPress 6.9.5 et 6.8.6.
WordPress 7.0.2, définition et niveau d’urgence
WordPress 7.0.2 est une version de sécurité, pas une évolution fonctionnelle ordinaire. Elle corrige une faille SQL facilitée et une seconde faille combinant une confusion de route REST et une injection SQL. WordPress.org classe les deux problèmes comme suffisamment sérieux pour recommander une installation immédiate et a activé des mises à jour forcées sur les sites compatibles avec les mises à jour automatiques.
La nuance est importante. Une mise à jour de maintenance peut sembler moins visible qu’un changement d’éditeur, mais elle touche le cœur qui traite les requêtes et les données. Un site qui ne montre aucune erreur en façade peut rester vulnérable dans son administration ou dans son API REST. Ne repoussez donc pas l’installation sous prétexte que votre thème ne change pas.
Si votre tableau de bord est déjà lent ou inaccessible, faites d’abord une sauvegarde et consultez notre guide du back office WordPress lent. La priorité reste toutefois de sortir d’une version affectée.
Quelles versions sont concernées
WordPress 7.0.2 corrige les deux problèmes pour la branche 7.0. WordPress 6.9.5 contient les deux correctifs, tandis que WordPress 6.8.6 corrige uniquement le premier problème, car la seconde vulnérabilité ne concerne pas cette branche. Les versions antérieures à 6.8 ne sont pas affectées selon l’avis officiel, mais elles restent anciennes et doivent faire l’objet d’un plan de migration.
Le cycle WordPress 7.1 bêta était également concerné. La bêta 2 inclut les deux correctifs. Elle ne doit pas être installée sur un site de production pour autant, car une version bêta est destinée aux tests de compatibilité et non à la stabilité quotidienne.
# Vérifier la version actuellement installée
wp core version
# Vérifier les mises à jour disponibles
wp core check-update
# Après sauvegarde, appliquer la version de maintenance
wp core update --version=7.0.2Adaptez la commande à votre branche. Si votre hébergeur gère les mises à jour automatiques, contrôlez l’état réel au lieu de supposer que l’opération est terminée. Une tâche planifiée peut avoir échoué pour une raison de droits, d’espace disque ou de connexion sortante.
Les deux vulnérabilités corrigées
Le premier problème est une injection SQL facilitée, signalée par TF1T, dtro et haongo. Une injection SQL permet à une entrée mal contrôlée d’influencer une requête vers la base de données. Selon le contexte, un attaquant peut lire des informations, modifier des données ou préparer une compromission plus large. Le mot facilitée ne signifie pas bénigne. Il décrit la manière dont les conditions d’exploitation sont réunies.
Le second problème associe une confusion dans une route de traitement par lots de l’API REST et une injection SQL. L’avis WordPress indique que la chaîne peut mener à une exécution de code à distance. C’est le point le plus préoccupant pour un site exposant l’API ou des extensions qui ajoutent des routes personnalisées. Les détails techniques complets sont volontairement à consulter dans les avis CVE et GHSA officiels, après mise à jour des installations.
Les deux failles portent les références CVE 2026 60137 et CVE 2026 63030. Une référence CVE facilite la corrélation entre le correctif, les scanners et les bulletins de sécurité. Elle ne permet pas à elle seule de conclure qu’un site a été attaqué. Pour cela, il faut examiner les journaux, les utilisateurs, les fichiers modifiés et les requêtes inhabituelles.
# Vérifier les journaux HTTP autour de la mise à jour
# Exemple à adapter à votre hébergeur
grep -Ei 'wp-json|batch|union|select|admin-ajax' access.log | tail -n 100
# Contrôler les comptes administrateurs via WP CLI
wp user list --role=administrator --fields=ID,user_login,user_registeredNe cherchez pas uniquement le mot CVE dans les journaux. Les attaques peuvent employer des encodages différents et viser une extension plutôt que le cœur. Une absence de trace évidente ne remplace pas une mise à jour.
Installer WordPress 7.0.2 depuis l’administration
La méthode la plus simple est d’ouvrir Tableau de bord, Mises à jour, puis de cliquer sur le bouton de mise à niveau. Faites une sauvegarde de la base et des fichiers avant l’opération. Vérifiez que le serveur dispose d’espace libre et que la sauvegarde est réellement lisible. Une archive créée mais impossible à restaurer ne protège pas le site.
Pendant l’installation, évitez de fermer l’onglet et ne lancez pas simultanément une mise à jour massive des extensions. La mise à jour du cœur doit être isolée pour que le diagnostic reste clair. Après le retour de l’administration, ouvrez la page d’accueil dans une fenêtre privée, testez un article, un formulaire et la connexion d’un compte non administrateur.
# Contrôles après mise à jour
wp core verify-checksums
wp plugin list --update=available
wp theme list --update=available
curl -I https://exemple.fr/
curl -I https://exemple.fr/wp-json/La vérification des sommes de contrôle confirme que les fichiers du cœur correspondent à la version officielle. Elle ne vérifie pas les extensions, le thème ou les fichiers ajoutés par un attaquant. Complétez le contrôle par une lecture des journaux et une comparaison avec votre sauvegarde de référence.
Que faire si la mise à jour automatique a déjà eu lieu
WordPress peut appliquer automatiquement une version de sécurité en arrière-plan. Regardez la version dans wp-admin/about.php ou avec WP CLI. Si le site est bien en 7.0.2, 6.9.5 ou 6.8.6 selon votre branche, le correctif du cœur est installé. Il reste nécessaire de tester le site, car l’absence d’un changement de code visible ne garantit pas l’absence de régression dans une extension.
Consultez aussi les e-mails de maintenance et les journaux de mise à jour de l’hébergeur. Si l’automatisation a échoué, sauvegardez puis lancez une mise à jour manuelle depuis l’administration ou WP CLI. Ne téléchargez pas un fichier zip depuis un miroir inconnu et ne remplacez pas des fichiers au hasard.
Pour les sites derrière un cache, purgez le cache de page après l’opération si l’hébergeur le permet. Le cache ne rend pas le cœur vulnérable ou corrigé, mais il peut servir une ancienne réponse et compliquer la vérification. Testez toujours l’URL avec un cache buster et depuis un navigateur privé.
Contrôler les extensions, le thème et l’API REST
Le correctif du cœur ne met pas à jour les extensions. Faites l’inventaire des extensions actives, en particulier celles qui ajoutent des routes REST, des imports par lots, des outils d’administration ou des accès directs à la base. Supprimez les extensions inutilisées au lieu de les laisser désactivées indéfiniment. Une extension abandonnée augmente la surface d’attaque et complique l’analyse.
Vérifiez que les extensions viennent d’une source fiable, que leur version est supportée et que leur changelog ne signale pas un conflit avec la version du cœur. Testez les formulaires, les webhooks, les éditeurs personnalisés et les synchronisations externes. Pour une erreur REST persistante, notre guide sur la réponse JSON invalide dans WordPress aide à séparer un problème de sécurité d’un problème de configuration.
# Inventaire des extensions et versions
wp plugin list --fields=name,status,version,update
# Lister les routes REST exposées par WordPress
wp eval 'foreach (rest_get_server()->get_routes() as $route => $data) echo $route . PHP_EOL;'Ne désactivez pas l’API REST globalement pour masquer le risque. Cela peut casser l’éditeur, les applications mobiles et des intégrations légitimes. Préférez une politique de permissions, des extensions à jour et un filtrage adapté aux besoins réels.
Rechercher des signes de compromission
Une mise à jour urgente ne prouve pas qu’un site a été compromis. Elle justifie cependant un contrôle proportionné, surtout si le site est resté longtemps sur une version vulnérable ou si ses journaux montrent des requêtes anormales. Vérifiez les nouveaux administrateurs, les changements d’adresses e-mail, les tâches cron inconnues, les fichiers PHP apparus récemment et les modifications de wp-config.php.
Comparez les fichiers du cœur avec les sommes officielles et examinez les extensions. Recherchez les modifications récentes dans wp-content/uploads, car ce répertoire ne devrait normalement pas contenir de scripts PHP exécutables. Contrôlez également les règles de redirection, les options d’accueil et les comptes de service utilisés par les intégrations.
# Fichiers PHP récents dans les téléversements
find wp-content/uploads -type f -name '*.php' -print
# Fichiers modifiés récemment, à examiner manuellement
find wp-content -type f -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %pn' | sort -r | head -n 100Ces commandes produisent des pistes, pas un verdict. Un fichier légitime peut être récent et un fichier malveillant peut avoir une date ancienne. En cas de suspicion réelle, isolez une copie, conservez les journaux et faites intervenir un spécialiste avant de supprimer des preuves.
Durcir le site après WordPress 7.0.2
Activez les mises à jour automatiques de sécurité si votre processus de sauvegarde et de supervision le permet. Utilisez des comptes nominatifs, limitez les droits administrateurs, imposez une authentification forte et supprimez les comptes inutilisés. Protégez les sauvegardes contre une écriture depuis le même compte que le site.
Réduisez l’exposition de l’API et de l’administration sans casser les fonctions utiles. Un pare-feu applicatif peut compléter la sécurité, mais il ne remplace pas la mise à jour du cœur. Contrôlez les permissions des fichiers, la version de PHP et les journaux de connexion. Pour un diagnostic plus large, notre audit WordPress avec WP Doctor fournit une checklist orientée sécurité, performance et SEO.
Enfin, documentez la version installée, la date de sauvegarde et le résultat des tests. Cette trace permet de savoir rapidement quels sites d’un parc ont reçu le correctif et lesquels nécessitent une intervention manuelle.
FAQ WordPress 7.0.2
WordPress 7.0.2 est-il obligatoire ?
WordPress 7.0.2 est fortement recommandé immédiatement, car cette version corrige deux vulnérabilités du cœur, dont une chaîne pouvant mener à une exécution de code à distance. Installez-la après une sauvegarde vérifiée.
WordPress 7.0.2 corrige-t-il une faille critique ?
Oui. L’avis officiel décrit une faille SQL critique et une autre vulnérabilité de gravité élevée associant une route REST par lots et une injection SQL. Les références sont CVE 2026 60137 et CVE 2026 63030.
Quelle version installer si j’utilise WordPress 6.9 ?
Les sites sous WordPress 6.9 doivent installer WordPress 6.9.5, qui contient les deux correctifs de sécurité. Les sites sous WordPress 6.8 doivent installer 6.8.6.
Comment vérifier que WordPress 7.0.2 est installé ?
Ouvrez Tableau de bord, Mises à jour, consultez la version affichée dans l’administration, ou lancez wp core version avec WP CLI. Complétez par wp core verify-checksums.
Faut-il changer les mots de passe après la mise à jour ?
Pas automatiquement si aucun signe de compromission n’existe, mais changez immédiatement les mots de passe si les journaux ou les comptes révèlent une activité suspecte. Révoquez aussi les clés d’API et les sessions concernées.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.