CVE-2026-60137 et CVE-2026-63030 : pourquoi une simple mise à jour WordPress peut éviter une compromission totale
Le 17 juillet 2026, WordPress a publié la version 7.0.2 pour traiter un problème critique et un problème de haute sévérité. Derrière cette annonce assez sobre se cachait en réalité un scénario beaucoup plus inquiétant qu'une simple faille isolée. L'avis de sécurité autour de la CVE-2026-60137 et de la CVE-2026-63030 montre comment deux faiblesses peuvent se combiner et faire basculer un site WordPress d'un simple bug de validation à une compromission beaucoup plus grave.
Le premier sujet porte sur le paramètre author__not_in de WP_Query. Pris seul, il ouvre un risque d'injection SQL dans certaines conditions. Le second porte sur une confusion de routage dans l'endpoint batch de l'API REST. Pris seul, ce n'est déjà pas une bonne nouvelle. Combinés, les deux peuvent ouvrir un chemin vers une exécution de code à distance sur certaines branches de WordPress. Et là, on ne parle plus d'un incident mineur, mais d'un scénario de compromission totale.
Ce que cela veut dire sans jargon
Une injection SQL, c'est le fait de faire exécuter à l'application une requête qui n'était pas prévue. Une confusion de routage, c'est le fait de tromper l'application sur l'endroit où la requête doit vraiment aller. Quand ces deux mécanismes se rejoignent, un attaquant peut parfois utiliser un simple point d'entrée applicatif pour aller beaucoup plus loin que prévu.
Ce qu'il faut retenir, c'est qu'un site WordPress peut sembler fonctionner normalement tout en étant techniquement exposé. Rien n'est visible pour le dirigeant, le commerçant ou le responsable marketing. Pourtant, tant que le cœur n'est pas corrigé, le risque reste présent.
Quelles versions sont concernées ?
D'après l'avis GitHub Security de WordPress, la CVE-2026-60137 touche les versions 6.8.0 à 6.8.5, 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Les versions corrigées ont été publiées en 6.8.6, 6.9.5 et 7.0.2. L'avis précise aussi que, à partir de WordPress 6.9, la combinaison avec le problème de routage REST peut mener à une exécution de code à distance.
Autrement dit, si votre site était encore en 7.0.0 ou 7.0.1 après le 17 juillet 2026, il ne fallait pas attendre. Et si votre maintenance WordPress repose sur une habitude du type on mettra à jour quand on aura le temps, cet épisode montre pourquoi ce raisonnement devient dangereux.
Pourquoi cette alerte doit intéresser même les petits sites
Beaucoup de TPE pensent qu'elles ne sont pas une cible faute de notoriété. C'est une erreur classique. Les attaques automatisées ne choisissent pas un site parce qu'il est célèbre. Elles le choisissent parce qu'il répond d'une certaine façon, avec une certaine version, un certain plugin ou une certaine signature technique.
Un site vitrine local, un blog pro, une page de prise de rendez-vous ou une boutique de niche peuvent être touchés exactement comme un gros site. Pour un attaquant automatisé, votre taille importe moins que votre retard de patch.
Que faire maintenant si vous avez un doute
- Vérifier la version du cœur WordPress en production.
- Appliquer sans attendre la version corrigée correspondant à votre branche.
- Mettre à jour en même temps les plugins sensibles liés aux requêtes et à l'API REST.
- Contrôler les comptes administrateurs, les utilisateurs récents et les modifications suspectes.
- Examiner les logs HTTP, PHP et serveur si vous avez du retard de maintenance.
- Tester les fonctions critiques après correctif : formulaires, checkout, espace admin, API tierces.
Pourquoi la mise à jour seule ne suffit pas toujours
Un site bien tenu ne se contente pas d'installer le correctif. Il vérifie aussi s'il y a eu exploitation avant patch, s'il existe des signes de compromission et s'il faut renforcer certains accès. C'est là que la différence entre mise à jour faite et site vraiment sécurisé devient visible.
Dans beaucoup de cas, les entreprises ont besoin d'un interlocuteur qui gère à la fois le cœur WordPress, les plugins, les sauvegardes, l'hébergement, les performances et le diagnostic en cas d'incident. Sans cette vision globale, on corrige un symptôme sans traiter les causes de fragilité.
Quand demander un support WordPress
Si votre site est ancien, si vous avez beaucoup d'extensions, si vous utilisez un constructeur de page, du WooCommerce ou des formulaires avancés, il est raisonnable de faire vérifier votre installation au lieu de croiser les doigts. Echo Dev peut vous aider à mettre en place une maintenance plus solide, des sauvegardes propres et un hébergement géré WordPress adapté à votre activité.
Si vous voulez un avis concret sur l'état de votre site, sur vos mises à jour ou sur vos risques actuels, vous pouvez me contacter via la page contact. Je peux intervenir en support, audit et remédiation WordPress.