Le 17 juillet 2026, l’équipe WordPress a publié en urgence les versions 7.0.2, 6.9.5 et 6.8.6. Elles corrigent deux vulnérabilités du cœur : CVE-2026-60137, une injection SQL, et CVE-2026-63030, une confusion de route dans l’API REST. Sur WordPress 6.9 et 7.0, leur chaînage permet à un attaquant non authentifié d’aller jusqu’à l’exécution de code à distance et à la prise de contrôle du site.

Ce qu’il faut retenir en 60 secondes

Référence Nature Versions touchées Correctif
CVE-2026-60137 Injection SQL facilitée dans WP_Query, sévérité élevée WordPress 6.8 à 7.0.1 6.8.6, 6.9.5 ou 7.0.2
CVE-2026-63030 Confusion route/handler de l’API REST, chaîne critique vers une RCE WordPress 6.9 à 7.0.1 6.9.5 ou 7.0.2

Les versions antérieures à 6.8 ne sont pas affectées par ces deux CVE selon l’avis officiel. Cela ne signifie pas qu’elles sont sûres : une branche ancienne peut contenir d’autres vulnérabilités et ne doit pas devenir une stratégie de contournement.

CVE-2026-60137 : une validation conditionnelle dans WP_Query

La première faille se situe dans le traitement du paramètre author__not_in par WP_Query. La valeur était correctement transformée en liste d’identifiants numériques lorsqu’elle arrivait sous forme de tableau, mais cette normalisation pouvait être évitée avec un autre type d’entrée. Une valeur non assainie pouvait alors être concaténée dans une clause SQL.

Prise isolément, cette primitive n’était pas directement pilotable par un visiteur dans le chemin REST normal : l’API devait valider le paramètre avant qu’il atteigne la couche de requête. C’est pourquoi l’avis WordPress la classe en sévérité élevée, et non critique. Le correctif force désormais la conversion de l’entrée en liste d’identifiants quel que soit son type initial.

CVE-2026-63030 : la couche REST ouvre le chemin d’exploitation

La seconde vulnérabilité concerne le point d’entrée des requêtes groupées de l’API REST. Une confusion entre la route contrôlée et le gestionnaire finalement exécuté permettait de faire valider une requête selon les règles d’une route, puis de la faire traiter par une autre. L’attaquant pouvait ainsi contourner la validation qui empêchait normalement une valeur malformée d’atteindre WP_Query.

Sur WordPress 6.9 à 7.0.1, cette faiblesse transforme l’injection SQL précédente en vecteur accessible sans compte utilisateur. L’avis GitHub de WordPress associe CVE-2026-63030 à une chaîne menant à la RCE. Le score seul raconte donc mal le risque : la gravité vient de l’assemblage de deux défauts présents dans des couches différentes.

Pourquoi le chaînage est critique

  1. Une requête atteint le mécanisme de traitement groupé de l’API REST.
  2. La confusion de route contourne les règles de validation attendues.
  3. La donnée non normalisée parvient au constructeur de requête SQL.
  4. L’injection permet d’accéder à des données sensibles de la base.
  5. Les secrets ou informations obtenus peuvent ensuite être utilisés pour prendre le contrôle du site et exécuter du code.

Cette chaîne a parfois été surnommée « wp2shell ». Le nom est parlant, mais il ne faut pas le confondre avec une troisième vulnérabilité : il désigne bien la combinaison de CVE-2026-60137 et CVE-2026-63030.

Quelles installations WordPress sont exposées ?

  • WordPress 7.0 et 7.0.1 : exposés aux deux failles ; mettre à jour vers 7.0.2 ou une version ultérieure.
  • WordPress 6.9 à 6.9.4 : exposés aux deux failles ; mettre à jour vers 6.9.5 ou une version ultérieure.
  • WordPress 6.8 à 6.8.5 : concernés par CVE-2026-60137 seulement ; mettre à jour vers 6.8.6 ou une version ultérieure.
  • Versions antérieures à 6.8 : non concernées par ces deux CVE d’après WordPress, mais potentiellement exposées à d’autres failles connues.

L’équipe WordPress a activé les mises à jour automatiques forcées pour les branches affectées. Il reste indispensable de vérifier : certaines installations bloquent les mises à jour automatiques, ne peuvent pas écrire sur leurs fichiers ou sont maintenues par un mécanisme de déploiement qui écrase les changements.

Plan de remédiation en quatre étapes

1. Confirmer la version exécutée

Contrôlez la version depuis le tableau de bord, votre outil de gestion de parc ou, si WP-CLI est disponible, avec wp core version. Ne vous fiez pas uniquement à la version attendue dans l’inventaire : vérifiez chaque instance, y compris les sites de recette, clones de migration et sous-domaines oubliés.

2. Sauvegarder puis mettre à jour

Réalisez une sauvegarde exploitable des fichiers et de la base, conservez-la hors du serveur, puis appliquez la version corrigée de votre branche. Vérifiez les sommes de contrôle du cœur avec wp core verify-checksums. Mettez aussi à jour les extensions et thèmes : ils ne causent pas ces deux CVE, mais peuvent offrir d’autres chemins de persistance.

3. Rechercher les signes d’une compromission

Examinez les événements survenus depuis le 17 juillet 2026 au minimum, et plus tôt si votre exposition est incertaine :

  • nouveaux comptes administrateurs, changements d’e-mail ou de mot de passe inattendus ;
  • fichiers PHP récents ou modifiés dans wp-content/uploads, mu-plugins, les thèmes et extensions ;
  • écarts de sommes de contrôle dans le cœur WordPress ;
  • tâches cron, options, plugins ou snippets inconnus ;
  • requêtes anormales vers l’API REST groupée dans les journaux du proxy, du serveur web ou du WAF ;
  • connexions sortantes inhabituelles du serveur PHP et processus système inattendus.

Patchstack indiquait dès le 17 juillet observer des tentatives d’exploitation. L’absence d’alerte d’un plugin de sécurité ne suffit donc pas à conclure que le site est sain.

4. En cas de doute, traiter comme un incident

Isolez l’instance sans détruire les preuves, capturez les journaux et une copie du système, puis faites analyser la chronologie. Après assainissement, renouvelez les salts WordPress, mots de passe administrateurs, accès à la base, clés API, secrets SMTP et identifiants d’hébergement susceptibles d’avoir été accessibles. Une simple réinstallation du cœur ne supprime pas nécessairement une persistance placée dans une extension, la base ou un autre compte système.

Réduire l’impact de la prochaine faille WordPress

  • Rendre les mises à jour mesurables : inventaire des sites, version remontée automatiquement et alerte sur toute instance hors politique.
  • Limiter les privilèges PHP : compte système dédié par site, droits d’écriture réduits et séparation entre environnements.
  • Centraliser les journaux : conserver les accès HTTP, changements de fichiers et événements d’administration hors du serveur WordPress.
  • Surveiller l’intégrité : comparer le cœur et les extensions aux sources officielles, détecter les ajouts dans les emplacements sensibles.
  • Tester la restauration : une sauvegarde non testée ne constitue pas un plan de reprise.
  • Préparer la réponse : savoir qui peut isoler un site, préserver les preuves, faire tourner les secrets et communiquer.

Un WAF peut réduire l’exposition pendant une fenêtre de correction, mais il ne remplace ni la mise à jour ni l’analyse post-incident. Pour une faille du cœur accessible sans authentification, le délai de réaction se compte en heures, pas en cycles mensuels de maintenance.

Sources

Conclusion

CVE-2026-60137 et CVE-2026-63030 illustrent un risque classique en sécurité applicative : deux faiblesses, limitées lorsqu’elles sont regardées séparément, deviennent critiques lorsqu’un attaquant les chaîne. Pour les versions WordPress 6.9 et 7.0 concernées, la priorité est double : installer immédiatement le correctif et vérifier si l’instance a déjà été compromise.