seolounge
- WordPress 7.0.2 est une mise à jour sécurité publiée le 17 juillet 2026.
- Deux failles sont concernées, CVE-2026-63030 et CVE-2026-60137.
- Le risque le plus fort touche les branches 6.9 et 7.0 non corrigées.
- Les correctifs à viser sont 7.0.2, 6.9.5, 6.8.6 ou 7.1 beta2 selon ta branche.
- Le point d’entrée à surveiller côté logs concerne la REST API batch.
- Après le patch, il faut vérifier comptes admin, fichiers récents, mu-plugins et traces SQL.
WordPress 7.0.2 vient de sortir avec un correctif qui demande une vraie vérification dans le back-office. Cette fois, le sujet touche le cœur WordPress, pas un plugin oublié sur un site laissé sans suivi. La mise à jour corrige une faille dans la REST API batch et une injection SQL dans WP_Query. Chaînées sur certaines branches, ces deux failles peuvent mener à une exécution de code sans compte WordPress.
Le nom qui circule déjà dans les discussions sécurité est wp2shell. Retenir ce nom aide pour suivre les alertes, mais le plus utile reste de savoir si ton site est dans la bonne version. WordPress a poussé des mises à jour automatiques forcées pour les sites concernés, ce qui limite une partie du risque. Mauvaise idée pourtant de croire que tous les sites sont réglés. Un hébergement ancien, une mise à jour bloquée, une compatibilité de thème ou une instance oubliée peut laisser une version exposée.
Le bon angle n’est pas de paniquer. Tu vérifies la branche, tu confirmes que le correctif est bien installé, tu regardes les logs autour du 17 juillet 2026, puis tu cherches les traces qui indiquent une tentative ou un accès réussi. Une mise à jour bloque le scénario connu, mais elle ne retire pas un fichier déjà ajouté ni un compte admin créé pendant la fenêtre d’exposition.
Ce qui change avec cette alerte cœur
La plupart des alertes WordPress récentes concernaient des extensions. WPForms, Smash Balloon, UpdraftPlus, Breeze Cache ou Avada ont déjà rappelé que le volume d’installations transforme un bug en sujet opérationnel. Ici, le contexte est plus large. Le correctif touche WordPress lui-même. Un site sans plugin vulnérable peut donc être concerné si sa branche WordPress entre dans la plage touchée.
La première faille, CVE-2026-60137, se situe dans WP_Query. Le problème vient du paramètre author__not_in quand une valeur non attendue arrive jusqu’à la construction de requête. En temps normal, cette valeur doit rester une liste propre d’identifiants. Si le nettoyage dépend trop du type reçu, une chaîne peut prendre un chemin moins contrôlé et finir dans une clause SQL.
La seconde faille, CVE-2026-63030, vise la REST API batch. Ce mécanisme permet de grouper plusieurs sous-requêtes dans un seul appel. Le bug vient d’une confusion entre la route validée et la route réellement exécutée. Quand les correspondances internes se décalent, une requête peut profiter d’un contrôle prévu pour une autre. C’est ce chaînage qui rend l’alerte vraiment sensible.
Pourquoi la branche 6.8 ne se lit pas pareil
La branche 6.8 demande une lecture à part. Elle est concernée par la faille SQL, mais pas par le même chaînage REST API batch annoncé pour les branches 6.9 et 7.0. Si ton site tourne en 6.8.6, le correctif SQL est bien là. Tu peux tout de même préparer le passage vers une branche plus récente, mais avec une sauvegarde propre et un test des extensions avant de toucher un site de production.
| Version vue dans WordPress | Lecture du risque | Action utile |
|---|---|---|
| 7.0.0 ou 7.0.1 | Chaînage complet possible | Passer en 7.0.2 sans attendre |
| 6.9.0 à 6.9.4 | Chaînage complet possible | Installer 6.9.5 puis planifier la suite |
| 6.8.0 à 6.8.5 | Faille SQL à corriger | Passer en 6.8.6 au minimum |
| 6.8.6 | Correctif SQL appliqué | Surveiller et tester une montée de branche |
| Avant 6.8 | Non touché par ces CVE selon WordPress | Vérifier quand même maintenance et extensions |
Le détail technique qui compte vraiment
Pas besoin de publier un mode d’emploi d’attaque pour comprendre le risque. Le point utile pour un admin, c’est le chemin logique. Une sous-requête mal alignée dans la REST API batch peut contourner un contrôle attendu. Une valeur qui aurait dû être validée comme liste d’entiers arrive alors dans WP_Query avec une forme inattendue. À partir de là, l’injection SQL devient exploitable dans un contexte que WordPress n’aurait pas dû exposer à un visiteur anonyme.
Ce mécanisme explique pourquoi certains rapports parlent de faille critique alors que l’une des deux CVE, seule, peut sembler moins impressionnante. CVE-2026-60137 devient beaucoup plus dangereuse quand CVE-2026-63030 lui donne un chemin atteignable sans connexion. La gravité ne vient pas seulement du bug SQL. Elle vient du duo.
Si tu veux revoir la base des injections, l’article sur les injections SQL côté site web complète bien ce point. Ici, le réflexe reste le même. On ne laisse jamais une valeur brute décider d’une requête. WordPress a corrigé la conversion vers une liste d’identifiants propre, ce qui coupe la partie SQL du scénario.
Contrôler l’exposition rapidement
Commence par le tableau de bord. Le widget d’un coup d’œil affiche la version installée. La page des mises à jour confirme si WordPress propose une version plus récente. Si le site est déjà en 7.0.2, 6.9.5 ou 6.8.6 selon la branche, note la date et passe à la vérification des traces. Si la version reste dans une plage vulnérable, lance une sauvegarde et applique le correctif.
Regarde ensuite le cache et le CDN. Un WAF ou un cache serveur peut avoir reçu une règle de protection avant la mise à jour, mais ce n’est pas une preuve que WordPress est corrigé. Le pare-feu réduit l’exposition. Le patch supprime la faiblesse. Tu as besoin des deux si le site a traîné avec une version exposée pendant quelques jours.
Dans les journaux web, cible surtout les appels vers la REST API batch. Les chemins à chercher sont wp-json batch v1 et rest_route batch v1. Ne cherche pas seulement un accès réussi. Des lots de requêtes malformées, des erreurs SQL, des codes 400 inhabituels et des séries venues d’une même adresse IP peuvent déjà indiquer une reconnaissance active.
Ce que tu notes dans ton suivi
Pour chaque site, garde une ligne simple. Domaine, branche WordPress, version avant correction, version après correction, heure du patch, présence ou non d’un WAF, période de logs disponible, anomalies trouvées. Ce suivi paraît basique, mais il évite de refaire trois fois le même contrôle quand plusieurs sites clients sont concernés.
Si tu gères un parc, trie par exposition publique. Les vitrines actives, boutiques, espaces membres, sites reliés à des formulaires clients et domaines oubliés sur le même hébergement passent avant un petit environnement fermé. Une vieille préproduction indexable peut être plus risquée qu’un site principal déjà suivi tous les jours.
| Zone à vérifier | Signal à chercher | Réaction propre |
|---|---|---|
| Journaux web | Appels wp-json batch v1 répétés | Isoler les IP et conserver les lignes |
| Base de données | Erreurs SQL ou requêtes anormales | Comparer avec la période habituelle |
| Comptes WordPress | Admin récent ou compte inconnu | Désactiver puis enquêter avant suppression |
| Fichiers | PHP récent dans uploads ou mu-plugins | Copier l’indice puis nettoyer |
| Search Console | Pages inconnues ou pics suspects | Contrôler sitemap, indexation et sécurité |
Pourquoi le patch ne suffit pas toujours
Un site corrigé aujourd’hui peut avoir été touché hier. C’est le point qui fait perdre du temps quand il est ignoré. Si un attaquant a déjà posé un fichier PHP, changé un mu-plugin ou ajouté un administrateur, WordPress 7.0.2 ne va pas retirer automatiquement cette trace. La mise à jour bloque le passage connu. Le nettoyage demande une vérification séparée.
Les indices les plus utiles restent souvent très ordinaires. Un fichier PHP arrivé dans uploads, un thème enfant modifié sans raison, un compte admin créé hors horaire, une extension activée puis désactivée, une tâche cron étrange, un sitemap qui se met à pousser des URL inconnues. Si tu vois ce type de signal, passe sur une logique de désinfection, pas seulement de maintenance.
Le service de nettoyage d’un WordPress compromis détaille justement les contrôles de fichiers, de base, d’accès et de Search Console à lancer quand le doute dépasse la simple mise à jour. Sur ce sujet, perdre dix minutes à préserver les logs vaut mieux que supprimer un indice utile trop vite.
Bloquer la REST API batch si le patch attend
Le meilleur correctif reste la mise à jour. Si tu ne peux pas patcher dans l’heure à cause d’un thème fragile, d’une boutique en plein trafic ou d’une recette client à valider, tu peux réduire l’exposition côté WAF. Le blocage temporaire des chemins wp-json batch v1 et rest_route batch v1 coupe le point d’entrée utilisé dans le chaînage documenté.
Cette mesure doit rester courte. Certains sites utilisent la REST API pour l’éditeur de blocs, des applications, des intégrations ou des appels internes. Bloquer trop large peut casser des fonctions légitimes. Le bon compromis consiste à protéger le batch anonyme, confirmer que l’admin et le front tiennent encore, puis appliquer la mise à jour dès que la fenêtre technique est possible.
Profites-en pour revoir les accès admin. Les failles critiques attirent souvent beaucoup de bruit. Des comptes faibles, une absence de double authentification ou un wp-login trop exposé ajoutent une autre couche de risque. Le dossier sur la protection du login WordPress complète bien le chantier si tu veux réduire les tentatives automatisées autour du tableau de bord.
Le bon ordre pour traiter l’alerte
Le plus propre tient en quelques actions. Tu identifies la version, tu patches vers 7.0.2, 6.9.5 ou 6.8.6 selon la branche, tu vides les caches utiles, tu contrôles les logs REST API batch, tu regardes les comptes admin, puis tu inspectes les fichiers récents. Si tout est calme, tu notes le résultat et tu passes au site suivant.
Si tu trouves une anomalie, ne mélange pas tout. Garde les traces, coupe l’accès suspect, sauvegarde l’état actuel, puis nettoie avec méthode. Une faille cœur WordPress corrigée vite peut rester une simple opération de maintenance. Une faille cœur WordPress corrigée après exploitation devient un vrai sujet de remise au propre.
Cette alerte rappelle surtout une chose très concrète. Les mises à jour automatiques aident, les WAF réduisent le volume de requêtes malveillantes, les hébergeurs peuvent pousser des règles vite, mais le dernier contrôle reste chez toi. Si ton tableau de bord affiche la bonne version et que tes logs restent propres, tu peux noter le contrôle comme terminé. Si une version exposée traîne encore, tu sais quoi faire maintenant.
