Ce qui est touché
Il s’agit d’une faille du cœur, pas d’une extension. Aucune hygiène de plugins ne vous en protège.
Les sites en 6.8.x ne sont pas exposés à la chaîne complète — la faille de l’API batch est apparue en 6.9 — mais ils ont besoin de la 6.8.6 pour la moitié « injection SQL ».
Comment la chaîne fonctionne
Deux failles, dont aucune ne suffit seule. CVE-2026-63030 est un défaut de logique dans le processeur batch de l’API REST, sur/wp-json/batch/v1. La validation et l’exécution tournent dans deux boucles distinctes. Quand wp_parse_url() échoue sur le chemin d’une sous-requête, l’erreur est ajoutée au tableau de validation mais pas au tableau des correspondances. Les deux tableaux se désalignent, et à partir de là chaque sous-requête suivante est dispatchée vers le mauvais gestionnaire.
Ce désalignement est toute l’astuce : une requête finit exécutée par un gestionnaire qui n’a jamais validé ses paramètres.
CVE-2026-60137 est une injection SQL dans le paramètre author__not_in de WP_Query, cotée 5,9 prise isolément — le genre de trouvaille qui dort d’ordinaire dans un backlog.
Chaînées, la confusion de routage livre des paramètres non validés à la requête injectable. Le chemin publié va de là à la création d’un compte administrateur, puis de ce compte à l’exécution de code via l’installateur d’extensions. Contrôle total du site, sans identifiants à aucune étape.
Bonne illustration du fait qu’une faille de sévérité moyenne n’est pas une faille de faible priorité. La CVE-2026-60137 seule vaut 5,9. Associée au bon défaut de routage, elle devient la moitié d’une 9,8.
Chronologie, et pourquoi elle compte
- 17 juillet 2026 — divulgation publique via un GitHub Security Advisory. Des preuves de concept publiques sont apparues sur GitHub en quelques heures.
- 21 juillet 2026 — la CISA ajoute les deux CVE à son catalogue des vulnérabilités activement exploitées.
- 22 juillet 2026 — publication de l’analyse technique complète de la chaîne.
Mettre à jour
WordPress.org a poussé des mises à jour automatiques forcées sur les installations concernées dont les mises à jour auto étaient actives. Ne supposez pas que cela vous couvre : les sites aux mises à jour auto désactivées, ceux sous gestion de version, et ceux dont les fichiers du cœur ne sont pas inscriptibles n’ont pas été mis à jour. Vérifiez ce que vous exécutez réellement :Faites une sauvegarde avant la mise à jour, pas après. Si la mise à jour se passe mal, vous voulez un point de retour ; s’il s’avère que vous étiez compromis, vous voulez une copie des preuves.
Vérifier si vous avez été touché
Corriger ferme la porte. Cela ne fait rien contre quelqu’un déjà entré. Trois contrôles, par ordre d’utilité : Comptes administrateurs inattendus. La chaîne publiée en crée un. Passez en revue chaque compte à droits élevés et sa date de création.wp-content.
wp-content/uploads n’est pour ainsi dire jamais légitime.
Si l’un de ces contrôles remonte quelque chose, traitez le site comme compromis : restaurez une sauvegarde antérieure au premier événement suspect, mettez à jour, puis faites tourner tous les mots de passe et clés d’API. Nettoyer fichier par fichier un site compromis en production finit rarement bien — voyez notre checklist pour durcir WordPress après cet incident.