WordPress 7.0.2 : mise à jour urgente contre deux failles de sécurité

WordPress 7.0.2 corrige deux failles de sécurité dans le cœur du CMS, dont une chaîne d’attaque pouvant mener à une exécution de code à distance sans authentification. La mise à jour a été publiée le 17 juillet 2026 et WordPress recommande de l’installer immédiatement. Voici comment vérifier votre version, sauvegarder correctement le site et contrôler que la mise à jour n’a rien cassé.

Cette alerte ne concerne pas une extension facultative : elle touche WordPress lui-même. Un site vitrine, une boutique WooCommerce ou un média peut donc être exposé même avec peu d’extensions. La bonne réponse n’est ni la panique ni une mise à jour aveugle en pleine journée, mais une intervention rapide, sauvegardée et vérifiée.

Ce que corrige WordPress 7.0.2

L’équipe de sécurité WordPress décrit deux problèmes : une injection SQL facilitée et une confusion de route dans l’API REST, combinée à une injection SQL, pouvant aboutir à une exécution de code à distance. Les références publiées sont CVE-2026-60137 et CVE-2026-63030.

Le second problème a été signalé par Adam Kues, chercheur chez Assetnote / Searchlight Cyber. Selon l’avis du chercheur, l’attaque ne nécessite ni compte connecté, ni extension particulière, ni configuration exotique : une installation standard touchée peut être visée par une requête anonyme. Les détails techniques complets ne sont pas publiés pour laisser le temps aux administrateurs de corriger leurs sites.

Quelles versions de WordPress sont concernées ?

Les versions à installer dépendent de la branche utilisée :

• WordPress 7.0.0 et 7.0.1 : mise à jour vers 7.0.2, qui corrige les deux vulnérabilités.
• WordPress 6.9.0 à 6.9.4 : mise à jour vers 6.9.5, qui contient les deux correctifs.
• WordPress 6.8 : cette branche n’est touchée que par la première vulnérabilité selon WordPress.org ; la version 6.8.6 apporte le correctif.
• WordPress 7.1 bêta 1 : elle est touchée par les deux problèmes ; la bêta 2 contient les corrections. Une bêta ne doit de toute façon pas être utilisée en production.

WordPress.org indique que les versions antérieures à 6.8 ne sont pas concernées par ces deux avis. Cela ne signifie pas qu’un ancien WordPress est sûr : seule la version la plus récente bénéficie d’un support actif complet. Un site très en retard peut cumuler d’autres failles, des incompatibilités PHP et des extensions abandonnées. Dans ce cas, il faut préparer une montée de version contrôlée plutôt que conclure qu’aucune action n’est nécessaire.

Vous aviez commencé à préparer la prochaine version majeure ? Le guide WordPress 7.1 : comment préparer son site avant la mise à jour reste utile, mais l’urgence du jour est différente : appliquer d’abord le correctif de sécurité adapté à la branche actuellement en production.

Comment vérifier la version de son site WordPress

Connectez-vous à l’administration, puis ouvrez Tableau de bord > Mises à jour. La version installée est affichée en haut de la page. Si WordPress propose 7.0.2, 6.9.5 ou 6.8.6, le site n’a pas encore reçu le correctif correspondant.

Ne supposez pas que la mise à jour automatique a fonctionné

En raison de la gravité, WordPress a activé des mises à jour automatiques forcées sur les versions affectées. Mais un hébergeur, une constante de configuration, un outil de gestion ou un problème d’écriture peut empêcher l’installation. Vérifiez la version réellement affichée et recherchez l’e-mail de confirmation envoyé par WordPress. L’absence d’alerte ne constitue pas une preuve.

Sur un parc de plusieurs sites, dressez une liste avec le domaine, la version du cœur, la date de la dernière sauvegarde et le résultat du contrôle. Cette trace évite d’oublier un sous-domaine, un ancien site événementiel ou une boutique secondaire.

La procédure de mise à jour recommandée

1. Vérifier la sauvegarde avant toute modification

Assurez-vous de disposer d’une sauvegarde des fichiers et de la base de données, stockée en dehors de l’hébergement actif. Vérifiez sa date, sa taille et la possibilité de la restaurer. Une archive vide, incomplète ou conservée uniquement sur le même serveur ne protège pas correctement contre un incident.

2. Choisir un créneau court et prévenir les personnes concernées

Pour un site vitrine simple, l’opération est généralement rapide. Pour WooCommerce, un espace membre ou un site à fort trafic, évitez une période de commandes ou de publications. Notez les transactions en cours et prévoyez une personne capable de valider immédiatement le parcours utilisateur.

3. Contrôler les extensions, le thème et la version PHP

Mettez à jour les composants compatibles et identifiez ceux qui ne sont plus maintenus. Le correctif WordPress reste prioritaire, mais une extension obsolète peut provoquer une erreur après le changement. Sur un site complexe, reproduisez l’opération dans un environnement de préproduction.

4. Installer la version corrigée depuis l’administration

Ouvrez Tableau de bord > Mises à jour, puis lancez l’installation proposée. N’interrompez pas l’onglet pendant l’opération. Si le site reste bloqué en mode maintenance ou affiche une erreur, conservez les messages précis et évitez les manipulations répétées qui compliqueraient le diagnostic.

5. Purger les caches et tester le site

Videz le cache de l’extension, du serveur et du CDN si nécessaire. Testez ensuite l’accueil, plusieurs pages, le formulaire de contact, la recherche, la connexion et les fonctions métier. Sur WooCommerce, contrôlez au minimum le panier, la commande test, les e-mails et le retour du moyen de paiement.

Une maintenance WordPress suivie permet d’organiser ces sauvegardes, mises à jour et contrôles sans attendre une alerte critique. Elle est particulièrement utile lorsqu’un site génère des demandes, des ventes ou des accès clients.

Que faire si la mise à jour est impossible immédiatement ?

La recommandation reste de corriger WordPress dès que possible. En mesure temporaire, Searchlight Cyber propose de bloquer l’accès anonyme à la route REST concernée, soit par une règle de pare-feu applicatif, soit en limitant l’accès à l’API REST. Cette protection de secours peut perturber des fonctions légitimes : formulaires, éditeur, application mobile, WooCommerce ou connecteurs.

Ne copiez pas une règle trouvée au hasard dans un fichier serveur sans comprendre sa portée. Faites d’abord une sauvegarde, documentez le changement et testez les fonctions dépendantes de l’API. La restriction doit rester provisoire, jusqu’à l’installation du correctif officiel.

• limiter l’accès à l’administration aux personnes indispensables ;
• contrôler les comptes administrateurs et supprimer ceux qui sont inconnus ou inutiles ;
• rechercher des modifications récentes inattendues dans les extensions, thèmes et fichiers ;
• consulter les journaux de sécurité et d’hébergement sans exécuter de scanner non maîtrisé ;
• préparer un plan de retour arrière avant toute intervention supplémentaire.

Les contrôles à effectuer après l’installation

• La page des mises à jour affiche bien 7.0.2, 6.9.5 ou 6.8.6 selon la branche.
• Le site public répond sans erreur sur ordinateur et mobile.
• Les formulaires transmettent les demandes et les e-mails arrivent.
• Les comptes administrateurs sont connus et les droits restent cohérents.
• Les tâches planifiées, sauvegardes et automatisations fonctionnent.
• Le panier, le paiement, le compte client et les webhooks sont testés sur une boutique.
• Aucune modification inattendue n’apparaît dans les fichiers ou contenus.

Si un comportement anormal apparaît, restaurez uniquement si cela est nécessaire et si la sauvegarde est fiable. Une restauration remet aussi l’ancienne version vulnérable : il faudra comprendre l’erreur, corriger le point de compatibilité et réappliquer la mise à jour. Pour un site ancien ou très personnalisé, une architecture WordPress propre et maintenable réduit fortement le coût de ces interventions.

Questions fréquentes sur WordPress 7.0.2

WordPress 7.0.2 est-il une mise à jour obligatoire ?

Elle n’est pas obligatoire au sens administratif, mais elle est fortement recommandée par l’équipe WordPress. Elle corrige une vulnérabilité critique et une vulnérabilité de sévérité élevée. Un site utilisant une version affectée doit être mis à jour sans délai inutile.

La mise à jour automatique suffit-elle ?

Seulement si elle a réellement abouti. Vérifiez le numéro de version dans le tableau de bord, l’e-mail de confirmation et le fonctionnement du site. Certains hébergeurs ou réglages peuvent désactiver ou bloquer les mises à jour automatiques.

Un pare-feu WordPress protège-t-il sans mettre à jour ?

Un pare-feu peut réduire temporairement l’exposition s’il dispose d’une règle adaptée, mais il ne remplace pas le correctif du cœur. Les règles d’urgence peuvent aussi bloquer des usages légitimes. La mise à jour officielle reste la solution durable.

Faut-il passer directement à WordPress 7.1 bêta 2 ?

Non sur un site en production. La bêta 2 corrige les vulnérabilités pour les environnements de test, mais une bêta peut contenir d’autres défauts. Utilisez la version stable corrigée de votre branche et réservez WordPress 7.1 à une préproduction.

Mettre à jour vite, puis vérifier sérieusement

WordPress 7.0.2 est un correctif de sécurité à traiter en priorité. La méthode la plus sûre tient en quatre points : identifier la version, valider une sauvegarde restaurable, installer le correctif puis tester les parcours réellement utilisés. Reporter sans protection prolonge l’exposition ; cliquer sans sauvegarde ni contrôle transforme une opération simple en risque de panne.

Sources

• WordPress.org — WordPress 7.0.2 Release, 17 juillet 2026.
• WordPress.org — documentation de la version 7.0.2, 17 juillet 2026.
• Searchlight Cyber — wp2shell: Pre Authentication RCE in WordPress Core, 17 juillet 2026.
• WordPress Developer Resources — sauvegardes WordPress.