WordPress 7.0.2, publiée le 17 juillet 2026, a corrigé wp2shell, une chaîne de deux failles du cœur (CVE-2026-63030, critique, et CVE-2026-60137) qui permettait à un visiteur non connecté d’exécuter du code sur un site en WordPress 6.9 ou 7.0, sans extension particulière. WordPress.org a forcé la mise à jour automatique des sites concernés. Mais en octobre 2026, la 7.0.2 ne suffit plus : installez la 7.1.3, ou à défaut le dernier correctif de votre branche. Voici ce qui a été corrigé, les versions touchées, comment vérifier votre site et quoi faire dans les dix prochaines minutes.
Mise à jour d’octobre 2026 : la version actuelle est la 7.1.3 (6 octobre 2026). Un site resté volontairement sur la branche 7.0 doit être en 7.0.7 (6.9.10 sur la 6.9, 6.8.11 sur la 6.8), d’après la liste officielle des versions consultée le 8 octobre 2026. Si votre site tourne encore en 7.0 ou 7.0.1, il cumule wp2shell et les failles corrigées depuis : passez à la 7.1.3, une version majeure dont je détaille les nouveautés de WordPress 7.1 et les points à vérifier avant de mettre à jour.
Ce que corrige WordPress 7.0.2 : la faille wp2shell
Cette version corrige deux failles, qualifiées dans l’annonce officielle de l’équipe sécurité de WordPress de « critique » pour l’une et de « gravité élevée » pour l’autre. Enchaînées, elles forment ce que les chercheurs ont baptisé wp2shell : une exécution de code à distance sans authentification, dans le cœur de WordPress lui-même, sans qu’aucune extension vulnérable soit nécessaire.
CVE-2026-63030 : la confusion de routes de l’API REST (critique)
La plus grave touche l’API REST, et plus précisément le point d’accès qui regroupe plusieurs requêtes en une seule (/wp-json/batch/v1). Depuis WordPress 6.9, une « confusion de routes » dans le traitement de ces requêtes groupées permettait à un visiteur anonyme d’atteindre du code normalement protégé. Combinée à l’injection SQL décrite ci-dessous, elle mène à une exécution de code à distance. C’est le scénario redouté : un attaquant qui exécute du code sur votre serveur sans aucun identifiant. La faille a été découverte par Adam Kues (Assetnote / Searchlight Cyber) ; l’avis de sécurité GHSA-ff9f-jf42-662q la classe critique.
CVE-2026-60137 : l’injection SQL dans author__not_in de WP_Query
La seconde est une injection SQL facilitée dans le paramètre author__not_in de WP_Query, la classe qui construit les requêtes de contenus. Présente depuis WordPress 6.8, elle a été signalée par TF1T, dtro et haongo. 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. L’annonce officielle la range en gravité élevée, l’avis GHSA-fpp7-x2x2-2mjf en gravité moyenne : seule, elle pèse moins que la première ; c’est leur combinaison qui ouvre la porte du serveur.
Côté code, la 7.0.2 ne modifie que trois fichiers du cœur (class-wp-rest-server.php, class-wp-query.php et rest-api.php, d’après la fiche officielle de la version) et n’apporte aucune fonctionnalité nouvelle.
Versions concernées et version à installer aujourd’hui
En juillet, WordPress 7.0 et 7.0.1 et la branche 6.9 étaient vulnérables aux deux failles, la branche 6.8 à l’injection SQL seule. Ces correctifs de juillet ne suffisent plus : la dernière colonne du tableau indique ce qu’il faut installer aujourd’hui.
| Branche | Versions vulnérables à wp2shell | Corrigée le 17 juillet 2026 par | Version à installer aujourd’hui |
|---|---|---|---|
| 7.0 | 7.0 et 7.0.1 (les deux failles) | 7.0.2 | 7.0.7, ou mieux 7.1.3 |
| 6.9 | 6.9 à 6.9.4 (les deux failles) | 6.9.5 | 6.9.10, ou mieux 7.1.3 |
| 6.8 | 6.8 à 6.8.5 (injection SQL seule) | 6.8.6 | 6.8.11, ou mieux 7.1.3 |
| Avant 6.8 | Non concernées par ces deux failles | Sans objet | 7.1.3 (d’autres failles corrigées depuis les touchent) |
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, et c’est un problème encore plus urgent : les trois failles graves corrigées depuis août touchent aussi ces anciennes versions (les correctifs ont été reportés jusqu’à la branche 4.7), et seule la dernière version de WordPress est activement maintenue.
7.0.2, 7.0.3, 7.0.4 : pourquoi la 7.0.2 ne suffit plus
Un site resté en 7.0.2 est protégé contre wp2shell, pas contre la suite. Les correctifs publiés depuis l’illustrent :
- 7.0.3 (6 août 2026) : douze correctifs de sécurité, dont un XSS réfléchi avant connexion sur l’écran de connexion, qui peut mener à l’exécution de code PHP si un administrateur se laisse piéger par un site malveillant (CVE-2026-64638) ;
- 7.0.4 (12 août 2026) : une exécution de code à distance par un compte Auteur ou plus, via l’envoi d’un fichier piégé, sur les serveurs qui utilisent Imagick et Ghostscript (CVE-2026-65640) ;
- 7.0.5, 7.0.6 et 7.0.7 (17 septembre, 22 septembre et 6 octobre 2026) : les correctifs de sécurité de 7.1.1, 7.1.2 et 7.1.3 reportés sur la branche 7.0, dont une traversée de répertoire critique exploitable sans authentification, qui peut mener à l’exécution de code selon la configuration du serveur et du thème (CVE-2026-87902, corrigée en 7.0.6).
Retenez la règle : la bonne version n’est jamais celle citée dans un article d’actualité, c’est la dernière de la liste officielle.
« Mon site se met à jour tout seul, non ? »
Bonne nouvelle : pour cette version, l’équipe WordPress a activé les mises à jour automatiques forcées sur les versions affectées. Les sites dont les mises à jour automatiques fonctionnent ont donc reçu le correctif sans intervention, puis les correctifs suivants de leur branche. Attention : ce mécanisme suit votre branche (de 7.0.2 à 7.0.7) ; selon le réglage choisi dans Tableau de bord → Mises à jour, le passage à la 7.1 peut rester à lancer vous-même.
Mais « automatique » ne veut pas dire « garanti ». 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 WP_AUTO_UPDATE_CORE réglée sur false, par le filtre automatic_updater_disabled ajouté dans un thème ou une extension, 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 documentation officielle sur la mise à jour de WordPress détaille ces réglages et leurs effets.
Deux types de messages doivent vous alerter. Dans Outils → Santé du site, « Toutes les mises à jour automatiques sont désactivées » ou « Les mises à jour de sécurité et de maintenance sont bloquées par… » signale un réglage bloquant. Le bandeau « Une mise à jour automatique de WordPress a échoué en cours de route » impose de relancer la mise à jour depuis Tableau de bord → Mises à jour : après un échec critique, WordPress suspend les mises à jour automatiques jusqu’à ce qu’une mise à jour manuelle réussisse.
La vérification prend trente secondes (les endroits où regarder sont détaillés juste après). Vous devez lire 7.1.3, ou le dernier correctif de votre branche (voir le tableau). Sinon, lancez la mise à jour maintenant : au sein d’une même branche, ces versions ne contiennent que des correctifs ; le risque de casse est minime, celui de ne pas l’appliquer ne l’est pas.
Comment savoir quelle version de WordPress vous utilisez
Trois endroits dans l’administration donnent la réponse :
- Tableau de bord → Mises à jour : la version installée et, le cas échéant, la version disponible ;
- le pied de page de l’administration, en bas à droite de chaque écran ;
- Outils → Santé du site → Infos, section « WordPress » : la version et plusieurs réglages du cœur, utiles à transmettre à un prestataire.
Si vous gérez plusieurs sites ou travaillez en ligne de commande, WP-CLI donne la même information, et un peu plus. Ces commandes ne modifient rien ; wp core verify-checksums compare les fichiers du cœur aux empreintes officielles de votre version :
# Version installée et mises à jour disponibles
wp core version
wp core check-update
# Fichiers du cœur modifiés ou ajoutés depuis l'installation
wp core verify-checksums
# Comptes administrateurs et date de création
wp user list --role=administrator --fields=ID,user_login,user_registeredSur les sites que je maintiens, je vérifie aussi chaque instance : la préproduction, l’ancien site resté en ligne sur un sous-domaine, la copie de test chez l’hébergeur. Un site que plus personne ne regarde est exactement celui que les scanners trouvent.
Pourquoi la fenêtre de temps a été si courte
Il y a une mécanique bien rodée après chaque version 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 ? ».
Pour wp2shell, cette fenêtre a été particulièrement courte : des preuves de concept publiques sont apparues dans les heures qui ont suivi la publication du correctif, et plusieurs sociétés de sécurité ont confirmé des attaques réelles dans les jours suivants, selon la FAQ publiée par Tenable le 20 juillet 2026.
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 publication : mise à jour appliquée, sauvegarde préalable, contrôle du site après coup. Pour les autres, chaque correctif 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, dans l’ordre :
- Vérifiez votre version dans l’administration ou avec WP-CLI, sur chaque instance du site.
- Si elle n’est pas à jour, faites une sauvegarde complète (fichiers + base).
- Lancez la mise à jour vers la 7.1.3, ou vers le dernier correctif de votre branche (7.0.7, 6.9.10, 6.8.11) si vous ne pouvez pas encore passer à la 7.1.
- Vérifiez ensuite les pages clés de votre site : accueil, formulaire de contact, tunnel de commande si vous vendez en ligne.
- Profitez-en pour mettre à jour vos extensions et votre thème en retard, qui restent la première porte d’entrée des piratages WordPress, loin devant le cœur.
- Si votre site est resté vulnérable après le 17 juillet, contrôlez la liste des administrateurs, l’intégrité des fichiers du cœur (
wp core verify-checksums) et les journaux du serveur à la recherche de requêtes versbatch/v1. Au moindre doute, changez les mots de passe administrateur, régénérez les clés et sels dewp-config.php(ce qui déconnecte toutes les sessions), puis traitez le site comme un piratage, pas comme une simple mise à jour.
Pour les journaux, le chemin dépend de l’hébergement. Sur un serveur avec accès SSH, une recherche comme celle-ci couvre les deux formes d’adresse du point d’accès (/wp-json/batch/v1 et ?rest_route=/batch/v1, éventuellement encodée) :
grep -iE "batch/v1|batch%2Fv1" /chemin/vers/access.logUne ligne trouvée n’est pas une preuve : l’éditeur de widgets de WordPress utilise aussi ce point d’accès. Ce qui doit alerter, ce sont des requêtes POST venues d’adresses inconnues entre le 17 juillet et la date de votre mise à jour.
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 : en moins de trois mois, cinq versions de sécurité ont déjà suivi la 7.0.2 sur la seule branche 7.0.
Questions fréquentes sur WordPress 7.0.2
Mis à jour en octobre 2026 : versions à installer et correctifs publiés depuis la 7.0.2.
À propos de l'auteur : Aurélien Kohler
