Le 17 juillet 2026, l’équipe sécurité de WordPress a publié la version 7.0.2, une mise à jour de sécurité qui corrige deux vulnérabilités sérieuses, dont une classée critique. Si votre site tourne encore en 7.0 ou 7.0.1 — ou sur une branche 6.8/6.9 non patchée — cet article vous concerne directement. Voici ce que corrige cette version, comment savoir si vous êtes exposé, et quoi faire dans les dix prochaines minutes.
Ce que corrige WordPress 7.0.2
Deux failles sont colmatées par cette version :
La première est une injection SQL facilitée (CVE-2026-60137), classée critique. Une injection SQL permet, dans le pire des cas, de lire ou modifier le contenu de votre base de données : comptes utilisateurs, mots de passe hachés, commandes clients sur une boutique WooCommerce.
La seconde touche la REST API : une confusion dans le traitement des requêtes batch pouvant mener à une injection SQL et, par enchaînement, à une exécution de code à distance (CVE-2026-63030, sévérité haute), découverte par les chercheurs d’Assetnote. C’est le scénario redouté : un attaquant qui exécute du code sur votre serveur sans aucun identifiant.
Concrètement, les versions affectées sont les suivantes : WordPress 7.0 et 7.0.1 sont vulnérables aux deux failles, la branche 6.9 aussi (corrigée en 6.9.5), la branche 6.8 est touchée par l’injection SQL uniquement (corrigée en 6.8.6). Les versions antérieures à 6.8 ne sont pas concernées par ces deux failles précises — mais si votre site est encore là, il traîne d’autres vulnérabilités connues bien plus anciennes, et c’est un problème encore plus urgent.
« Mon site se met à jour tout seul, non ? »
Bonne nouvelle : pour cette release, l’équipe WordPress a activé les mises à jour automatiques forcées sur les versions affectées. Une majorité de sites ont donc déjà reçu le correctif sans intervention.
Mais « une majorité » n’est pas « tous ». Les mises à jour automatiques peuvent être désactivées sans que vous le sachiez : par une constante AUTOMATIC_UPDATER_DISABLED ou DISALLOW_FILE_MODS dans le wp-config.php, par certains hébergeurs qui gèrent les mises à jour à leur façon, par un déploiement via Git ou Composer, ou par une extension d’optimisation un peu zélée. J’ai vu des sites convaincus d’être à jour tourner avec six mois de retard.
La vérification prend trente secondes : dans votre tableau de bord, Tableau de bord → Mises à jour, ou en pied de l’écran d’accueil de l’administration. Vous devez lire 7.0.2 (ou 6.9.5 / 6.8.6 si vous êtes volontairement resté sur une branche antérieure). Si ce n’est pas le cas, lancez la mise à jour maintenant — c’est une release de sécurité pure, sans changement fonctionnel : le risque de casse est minime, le risque de ne pas l’appliquer ne l’est pas.
Pourquoi la fenêtre de temps est si courte
Il y a une mécanique bien rodée après chaque release de sécurité : le correctif publié révèle, par comparaison du code, l’emplacement exact de la faille. Dans les heures qui suivent, des scanners automatisés balaient le web à la recherche des sites non patchés. Vous n’êtes pas attaqué parce que votre site est intéressant ; vous êtes attaqué parce qu’il est vulnérable et détectable. La question n’est donc pas « qui m’en voudrait ? » mais « combien de temps vais-je rester dans la liste des cibles faciles ? ».
C’est exactement le genre d’épisode qui illustre la différence entre un site maintenu et un site livré à lui-même. Mes clients sous forfait de maintenance WordPress étaient patchés et vérifiés le jour de la release — mise à jour appliquée, sauvegarde préalable, contrôle du site après coup. Pour les autres, chaque release de sécurité est une loterie dont on ne connaît le résultat que trop tard. Et si vous découvrez cet article après coup, avec un site au comportement étrange — redirections inconnues, contenus injectés, alertes de votre hébergeur — ne mettez pas simplement à jour en croisant les doigts : une mise à jour ne désinfecte pas un site déjà compromis. C’est un cas de dépannage WordPress à traiter sérieusement, restauration et analyse comprises.
La checklist des 10 minutes
Pour être en règle avec cette release, dans l’ordre : vérifiez votre version dans l’administration ; si elle n’est pas à jour, faites une sauvegarde complète (fichiers + base) puis lancez la mise à jour ; vérifiez ensuite les pages clés de votre site (accueil, formulaire de contact, tunnel de commande si vous vendez en ligne) ; et profitez-en pour mettre à jour vos extensions en retard, qui restent la première porte d’entrée des piratages WordPress, loin devant le cœur. Si vous voulez comprendre ce qu’une protection sérieuse implique au-delà des mises à jour, j’ai détaillé le sujet dans mon article sur la sécurité WordPress de niveau expert.
Et si vous préférez ne plus jamais avoir à lire ce genre d’article en urgence, c’est précisément le rôle d’un contrat de maintenance — j’en ai comparé les tarifs et ce qu’ils couvrent réellement dans un guide dédié. La prochaine faille critique ne préviendra pas non plus.
FAQ
Mon site est en WordPress 6.8 ou 6.9, suis-je concerné ?
Oui. La branche 6.9 est vulnérable aux deux failles (corrigées en 6.9.5) et la 6.8 à l’injection SQL critique (corrigée en 6.8.6). Si vous restez volontairement sur une branche antérieure à 7.0, vérifiez que vous êtes bien sur ces versions de correctif. En dessous de 6.8, ces deux failles précises ne s’appliquent pas, mais votre version n’est plus maintenue : le problème est plus large.
La mise à jour 7.0.2 peut-elle casser mon site ?
Le risque est très faible : c’est une release de sécurité pure, sans changement fonctionnel ni modification de la base de données. La seule vraie précaution est une sauvegarde préalable — un réflexe qui doit accompagner toute mise à jour, même mineure.
Comment savoir si mon site a été compromis avant le correctif ?
Les signes classiques : redirections vers des sites inconnus, contenus ou liens que vous n’avez pas créés, comptes administrateurs inconnus, alertes de Google Search Console ou de votre hébergeur, chute soudaine de trafic. Un scan avec Wordfence donne un premier diagnostic. En cas de doute sérieux, ne vous contentez pas de mettre à jour : une mise à jour ne nettoie pas une infection déjà en place.
J’ai un contrat de maintenance : dois-je faire quelque chose ?
Si votre prestataire fait sérieusement son travail, non — la mise à jour a dû être appliquée dans les heures suivant la publication, sauvegarde comprise. Un bon test de la qualité de votre contrat : demandez-lui à quelle date votre site est passé en 7.0.2. La réponse (et sa rapidité) vous en dira long.
